f X 

AO-A054  096  MICHIGAN  UNIV  ANN  ARBOR  DEPT  OF  INDUSTRIAL  AND  OPERA--ETC  F/6  9/2  X 

USER  REQUIREMENTS  LANGUAGE  (URL)  USER'S  MANUAL.  PART  I.  (DESCRI— ETC (U) 

MAR  77  D TEICHROEWf  A HERSHEY.  S SPEWAK  F19628-76-C-0197 

UNCLASSIFIED  ESD-TR-76-127-V0L-1  NL 


1 “=3 

ADA 

054096 

a 

a 

r? 

Sr 

; . 

Vi*;. 

:'>-.VUir 

a- 

f 

rr 

- ' ’ ‘.Ww 

i 

' i 

1, 

F 

' i * 

Ip 

rr 

fv 

ti 

V,2. 

r, 

r:'. 

* 

- 

T % 

« ^ 

ADA054096 


r 


ESP-TR-78-f27,  Vot.  I 


USER  REQUIREMENT  S LANGUAGE  (URL) 
USER'S  MANUAL  PART  I (DESCRIPTION) 
H6r8(^MULTICVVERSION  3.2 


D.  TEICHROEW 
A.  HERSHEY 
S.  SPEWAK 
University  of  AAichigon 

Department  of  Industrial  & Operations  Ertgineering 
Ann  Arbor,  Ml  48f09 


March  1977 


Approved  for  Public  Release; 
Distribution  Unlimited. 


Prepared  for 

DEPUTY  FOR  TECHNICAL  OPERATIONS 
ELECTRONIC  SYSTEMS  DIVISION 
HANSCOM  AIR  FORCE  BASE,  MA  01731 


D D C 

Pin^gnn  nr?\ 

MAY  15  1978 


MSHTUTL 

(VD 


t 


LEGAL  NOTICE  » 

When  U.  S.  Government  drawings,  specifications  or  other  data  ore  used  for  any 
purpose  other  than  a definitely  related  government  procurement  operation,  the 
government  thereby  incurs  no  responsibility  nor  any  obligation  whatsoever;  and 
the  fact  that  the  government  may  have  formulated,  furnished,  or  in  any  way  sup- 
plied the  said  drawings,  specifications,  or  other  data  is  not  to  be  regarded  by 
implication  or  otherwise  os  in  any  manner  licensing  the  holder  or  any  other  person 
or  conveying  any  rights  or  permission  to  monufocture,  use,  or  sell  any  oatented 
invention  that  may  in  any  way  be  related  thereto. 


OTHER  NOTICES 


Do  not  return  this  copy.  Retain  or  destroy. 

This  Technical  Report  has  been  reviewed  and  Is  approved  for  publication. 


\ AoU.0L\aA- 

JOHN  T.  H(}LLAND,  Lt  Colonel,  DSiF 
Chief,  Techniques  Ekiglneerl:^  Division 


FOR  THE  COMMANDER 


Deputy  for  Technical  Operations 


DISCLAIMER  NOTICE 


THIS  DOCUMENT  IS  BEST  QUALITY 
PRACTICABLE.  THE  COPY  FURNISHED 
TO  DDC  CONTAINED  A SIGNIFICANT 
NUMBER  OF  PAGES  WHICH  DO  NOT 
REPRODUCE  LEGIBLY. 


ASSIFICATION  OF  THIS  PACE  (Wh0n  Dmtm  Enfr^d) 


UTLE  (fnd  Subtitf) — 

USER^REQUfREMENTS  j^ANGUAGE  (U_RL) 
USER'S  ^NUAL.PART  j;(DESCRIPTlON) 
■'h6i9«i/multicsAersionX2  . 


10.  PROGRAM  CLEMENT.  PROJECT.  TASK 
AREA  A WORK  UNIT  NUMBERS 


;)PE64740L^ 


anization  name  and  address 

University  of  Michigan  ^ 

Department  of  Industrial  & Operations  Engineering 
Ann  Arbor,  Michigan  48109  , , 


II.  controlling  OEFICE  NAME  AND  ADDRESS  X j 

Deputy  for  Technical  Operations  f / f J 

Electronic  Systems  Division 
Hanscom  AFB,  MA  01731  1 I9I 


<47  MOiitTORINS^AeenCI'  NA|4E  a ADDRESSCI/  dllUrtnl  Irom  Controlllnt  Olllcm)  IS.  SECURITY  CLASS,  (ol  Ihit  rtport) 

/^juvd^p  0 \ UNCLASSIFIED 


Mar<»  W77/ 


IS«.  OCCLASSiFtCATlON/OOWNGRAOiNG 
SCHEDULE 


IS.  DISTRIBUTION  STATEMENT  (o!  tbia  Rmport) 


Approved  for  Public  Release;  Distribution  Unlimited. 


17.  Distribution  statement  (ot  rh«  aStfrucf  •nf«r«</in  Block  30,  if  difforont  from  Roport) 


19.  KEY  WORDS  (Contlnuo  on  rovorao  oldo  If  nocoaamry  ond  idontity  by  block  numbor) 


Computer-Aided  Design 
Information  Processing 
Information  System  Requirements 
Requirements  Analysis 


Requirements  Language 
Requirements  Specification 
Specification  Analysis 


ABSTRACT  (Continuo  on  rovrao  alda  If  riocoaaary  and  Idantity  bv  block  numbar) 

This  report  is  port  of  a series  that  deals  with  a Computer-Aided  Design  and  Specification 
Analysis  Tool  (CADSAT).  The  purpose  of  the  tool  is  to  describe  the  requirements  for 
information  processing  systems  and  to  record  such  descriptions  in  machine-processable  form. 
The  major  components  of  CADSAT  are  the  User  Requirements  Language  (URL)  and  the  User 
Requirements  Analyzer  (URA)  which  can  operate  in  an  interactive  computer  environment. 
This  report,— Part  I ondPort  44,^^escribes  how  the  formal  URL  may  be  used  to  define  systems. 
6*i^9JC)\'ti  available,  their  use  and  application  on  a Honeywell 


DD  1473 


EDITION  or  >vNOV  «S  IS  OBSOLETE 


security  CLASSIFICATION  OF  THIS  RACE  r<e»n  Dmtm  Bnfrtd) 


Aj} 


i 


PREFACE 


This  manual  describes  the  User  Requirements 
Lanugage  (URL)  to  be  used  with  Version  3.2 
of  the  User  Requirements  Analyzer  (URA). 

The  manual  consists  of  two  volumes  which 
are  referred  to  as  Part  I and  Part- II  in  the 
documentation.  Part  I gives  a detailed 
description  of  the  URL  statements  available 
and  their  use.  Part  II  is  a reference  manual 
which  gives  the  proper  syntax  for  each 
statement  . 
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FOREWORD 


rtsof  F*>auiret*f»nt  s Lanquage  is  a language  for  describing  an 

Tnf orirat. ion  Processing  Systen  (IPS).  A Problea  Stateaent  (PS) 
in  HPl  can  be  used  *■  o describe  the  "present"  systei  or  to  state 
requ i remen^-s  that  a "proposed"  ♦•arqet  systea  is  to  fulfill. 

Descrihinq  ♦•he  "present"  system  is  helpful  in  finding  where 
redundant  information  exists,  standardizing  procedures,  etc., 
and  also  forms  th®  basis  for  designing  "proposed"  systems.  In 
<^oscribim  a "prooosed"  system,  the  Problem  Statement  can  be 
considered  as  ♦he  specifications  for  the  succeeding  stages  in 
♦h^  system  life  cycle,  i.e.,  in  the  physical  design  and 
construction  phases. 

Peouirements  for  proposed  information  processing  systems  are 
usually  described  in  the  Logical  System  Design  phase  sometimes 
called  ♦he  "feasibility  study."  The  end  result  of  the  logical 
system  desion  nrocess  is  a description  of  a proposed  system  and 
a bencf i t/cos*  analysis  of  the  value  of  building  it.  The 
process  itself  may  be  accomplished  in  many  different  ways  but 
the  particular  method  chosen  loes  not  affect  the  form  of  the 
final  result.  wha^  constitutes  a satisfactory  description  of 
the  proposed  system  is  not  affected  by  whether  the  process  is 
carried  out  manually  or  with  computer  aids  (except  for  the  fact 
that  the  computer-aided  method  can  result  in  the  description 
itsolf  being  scored  in  a computer-aided  processable  form). 

"■he  Durpos®  of  the  manual  is  to  describe  how  UPL  may  be  used  to  j 

describe  systems.  Tt  may  be  used  as  an  introduction  to  the  use 
of  II ^L  and  is  also  used  as  a text  in  fJPL  courses.  It  contains 
the  complete  syntax  and  semantics  of  ORL  as  well  as  providing 
guidelines  on  how  these  are  intended  to  be  used.  A more  precise 
s♦a^eme^t  of  U"L  is  oiven  in  the  User  Reouirements  Language, 

Tanniaa®  Reference  Manual,  Part  IT.  Additional  information  in 
the  use  of  DP*  uiven  in  the  User  Requirements  Analyzer  User's 
flanual . 
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1.  TN^r  r-MA’^^OV  PCOCFSSTNR  SYSTEM  CESCPIPTION 

’’nformi^- ion  Proc'^ssinq  Systems  of  all  types  exist  in 
or'i a n i7a tion s ♦'O'lav.  ''hey  serve  to  store,  retrieve,  maninulate 
or  otqani'^e  information  in  some  manner  to  meet  a particular 
orqa  ni  ration  • s neo'is.  ’'or  this  reason,  the  design  and  operation 
of  one  of  these  systems  are  nacticiilar  to  a given  organization. 
To  conform  with  th=>  changing  environment,  an  organization  must 
d^veicD  new  systems,  modify  existing  systems  and  terminate 
obsolete  ones.  This  can  require  a raaior  effort  of  the 
orqaniration  fo  lesion  systems  and  maintain  documentation  of  a 
svstpm  one®  it  is  operational. 


Tntrodiict  ion 
1 . . 1 llsJ:ejjj  Life  Cycle 

An  information  nroc®ssinn  system  has  a life  cycle  which  begins 
with  tjip  initial  conception  of  need  of  the  system,  proceeds 
throuoh  determination  of  requirements  for  the  system,  (logical 
svstpm  desiqn) , nhvsical  system  design,  detailed  design  and 
construction,  operaticn,  modification  and  maintenance  and 
finally,  termination  cf  system  operation. 


t , . 2 oocum°ntat  jon 

At  oach  step  of  the  life  cycle,  some  form  of  documentation  is 
noa,lc(1  bv  •■ho  organization.  '^'he  documentation  consists  of  a 
comnlete  and  comprehensive  description  of  the  proposeed  (or 
tarqot)  systoni.  Tn  addition,  the  organization  of  which  the 
svstoifl  is  nart  must  he  at  least  partially  described;  and  the 
nro-^ect  defining  and  designing  the  system  must  also  be 
dosoribf d. 


’ . ^ . / . 1 What  h^s  to  be  documented 

Vo  matter  what  typo  of  system  is  to  be  designed  or  who  is 
desionina  it,  there  exist  some  features  or  components  which  are 
commrn  to  all  svstens  and  that  must,  therefore,  be  included  in 
its  documentation.  "oqother,  these  common  characteristics  can 
ba  regarded  as  constituting  a model  of  the  system.  This  model 
i s shown  in  ^iqu re  •*  . 

■'he  tasic  purpos-a  ^or  constructing  a system  is  to  serve  some 
• organization.  Usually,  a new  system  is  required  to  solve  some 

’’nrohlem"  within  tho  existing  system. 
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Piguro  1:  The  Problem 


“he  ♦•asV  of  '■he  syK'^em  builders  is  to  accurately  define  the 
problem  so  that  a solution  may  be  iirclemented . The  problem, 
♦■herefere,  has  three  basic  co'nponen*‘s  or  elements: 

- An  environment  in  which  the  problem  occurs.  Those  parts  of 
♦■he  orqaniration  which  directly  interface  with  the  problem  must 
h»  included  in  the  description. 

- '"h  “ tenet  system  which  is  being  described  to  resolve  the 
problem.  The  word  "target"  connotes  a "pronosed"  rather  than  an 
existina  system,  "^he  relation  between  the  environment  and  the 
target  system  is  shown  in  ^iauto  1. 

- “he  Proiert  assioned  the  task  of  defining  tho  problem, 
a^eaiiately  docum^ntirg  the  r egu irements , designing,  constructing 
and  installing  the  system. 

All  of  the  elements  must  be  documented  in  sufficient  detail  to 
m“et  the  ne^ds  of  the  organization.  To  accomplish  this,  the 
elements  miist  be  broken  down  to  smaller  comoonents.  These  in 
turn  must  he  broken  down  or  subdivided  into  smaller  elements. 

“he  elements  at  all  levels  are  called  the  "system  description 

p| um ent  s , " 


' . ^ . 2 . ? Pur  DO  sec;  of  Documentation 

“he  degrription  of  the  problem  thrcuqhout  the  life  cycle  is 
usually  referred  to  as  "documentation,"  Such  documentation  must 
servo  a number  of  different  purposes: 

- The  svstam  huillers  must  have  a record  of  what  they  have  done. 

- “he  organ i 7 at i ons  within  the  environment  of  which  the  system 
is  to  serve  must  have  a description  to  assure  themselves  that 
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♦•h"  prooar<?^  svstpir  will  sati'-.f-y  their  needs. 

- ""ho  manaaem ’nt  of  t orqanization  that  is  orovidinq  the 
r‘'sources  nust  know  what  they  are  approvinq. 

- ""Via  system  huild^rs  who  will  continue  the  development, 
const  rue ion  , opera*-icn  and  maintenance  of  the  system  must  all 
have'  documentation  from  which  tc  carry  out  their  tasks. 

Form s of  Poe umentati on 

■^o  serve  their  needs,  mos*-  orqanizations  have  developed  standard 
documentation  procedures  coiisistir.q  of  very  qeneral  to  very 
soecific  quidelines  in  producinq  documentation.  Some 
orq a n iza t ion s use  commercial  documentation  packages  or 
documentation  tochnirrues  in  hopes  cf  producinq  more  complete, 
correct  and  consistent  documentation. 

It  is  standard  practice  to  record  the  description  of  the  system 
in  formal  documents  corresponding  to  various  stages  of  the  life 
cvcle  Vnown  by  such  names  as  the  system  definition  report, 
svs*"^™  ropui reme nts  report,  system  design  report,  programming 
documentation,  user’s  manual,  etc. 

'’’hese  documents  are  normally  in  narrative  form,  supplemented  by 
diagrams.  Flow  char’-s,  lists,  glossaries,  cross  references,  etc. 

1.1.7.11  Chara  c’-erist  jes  of  S_ystem  rocumentatjon 

Information  Processing  gysteras  are  large  and  complex  and 
regardless  of  who  produces  the  documentation  or  what  graphical 
aids,  such  as  flow  charts  are  used,  it  will  have  several 
features  that  make  the  process  of  documentation  different. 

- 7ize.  Completo  do ru mentat ion  of  a system  mav  consist  of  many 
thousand  of  pages  of  charts,  tables,  code  listings,  user  guides, 
orodect  plans,  etc. 

- Complexity.  ^ny  piece  of  information  about  some  aspect  of  the 
svsteni  or  the  proiect  may  be  related  to  many  other  pieces. 

- ■'ultirle  users  with  different  needs.  Each  of  the  users  of  the 
documentation,  as  noted  above,  need  the  documentation  of  some 
asoects  of  the  svstem  at  different  levels  of  detail. 

- Ch anoeahil i t V.  The  documentation  must  be  constantly  updated 
as  changes  occur  in  the  organization  or  in  the  system.  Any 
change,  because  of  the  complexity,  can  affect  the  documa ntation 
in  many  places. 
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1.1.3  ^oc  u mentati  on 


1.1. 3.1  Manual 

‘^T'l.jcpp  must  bo  rornonsible  for  this  documentation.  It  is  often 
the  tast  of  th®  analyst  to  do  this.  In  other  cases,  it  nay  be  a 
technical  writer  who  must  obtain  the  information  from  other 
soirees  (analysts,  manaqeropnt,  memos,  etc.)  in  order  to  produce 
the  document ation  of  th®  system.  The  technical  writer  has  the 
disadvantaqe  of  not  beim  directly  involved  in  the  system 
devp  Icym  ent  effort.  The  analyst  has  the  advantaqe  of  being 
directly  involved  with  the  system  yet  is  sometimes  too  close  to 
it  to  present  a comnleto  description.  The  documentation  is 
usually  oroduced  manually  regardless  of  who  is  doing  it. 


1 . 1 . . 2 Comou  ter-  Aid  ed  Documentation  - U RL/UP  A 

A comruter-a ide 1 approach  to  system  documentation  can  be  an 
improvement  over  the  manual  methods  by  using  the  power  of  the 
computer  to  store  larqe  quantities  of  data  and  to  manipulate 
complex  relationships. 

"■q  talce  advantaqe  qf  th.a  potential  benefits,  a computer-aided 
documentation  system  should  have  the  following  characteristics: 

a)  A formal  language  flexible  enough  to  describe  any  type  of 
information  processing  system. 

b)  A translator  which  takes  the  formal  language  statements  as 
input  and  stores  it  in  some  processable  form  in  the  computer 
(i.e.,  on  disk  or  t^pe). 

c)  A data-base  in  which  the  information  interpreted  from  the 
language  s*:  a t om.i  nts  is  stored, 

d)  A report  q"n'»rator  which  allows  information  in  the  data-base 
to  be  retrieyoi,  analvred  and  formatted  as  reports. 

e)  An  update  facility  which  allows  information  in  the  data-base 
to  be  added  to,  modified,  or  deleted.  Before  any  information  in 
the  data-base  is  updated,  checks  must  be  made  for  consistency 
and  correctness  so  that  accuracy  of  the  information  in  the 
data-hase  is  maintained. 

'''he  advantages  of  using  such  a computer-aided  technique  versus  a 
manual  n“thod  aro: 

a)  •'■hough  information  is  interrelated  with  other  information, 
there  is  only  on®  occurrenc-*  of  each  piece  of  information  in  tha 
data-hase.  If  this  piece  of  information  is  modified,  tha 
contents  of  the  data-hase  are  modified  to  reflect  the  change. 
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*>)  Iincfuaqe  hir;  a fini+'.e  rumher  of  statements  which  may  be 

soecifiefl  and  syntax  and  semantic  rules  for  each  of  these 
statements.  This  allows  persons  documenting  systems  to  give 
precise  d'^scr  lot  ions  which  are  much  less  subgect  to 
misi  n*-“rpreta  tion. 

c)  Cnee  the  da*- a-base  has  been  modified,  all  reports  generated 
usii.q  i*-  are  up-to-da*-©, 

d)  ’’’he  reports  aenerated  are  designed  to  view  the  system  (as 
de.scribed  in  the  data-base)  at  various  angles.  One  particular 
report  may  present  high  level  structural  information,  another 
may  presen*-  the  manner  in  which  low  level  data  is  manipulated  in 
the  system,  and  sti)  1 others  may  present  lists  of  names, 
dictionaries,  *»tc. 

e)  Seme  reports  may  present  results  of  complex  analysis  based 
on  the  con*-ent.<-;  of  the  data-base.  Analysis  may  consist  of 
cheeVs  for  coraoleteness  or  consistency  in  the  system  description 
at  any  point  in  time. 

1. 1.  ■>.  3 npt/npiF 

'’“t,  in  a com puto r-nr ocessabl“  language  designed  primarily  to 
describe  a target  system  during  its  formative  stage  (i.e., 

'’urina  the  d etor  mina  t ion  of  reguirements  phase  in  the  system 
li*"©  cycle).  It  also  contains  facilities  for  describing  those 
parts  of  the  org ani-» a t i on  interfacing  with  the  system  and  those 
parte  of  tha  nroiect  which  are  relevant  to  the  description  of 
tpa  targe*-  system.  The  gPL  description  of  a system  consists  of 
a combination  of  formal  statements  (allowed  by  the  language) 
supplemented  by  narrative  descr ipt ions. 

■'he  ”rer  Peouiremerts  Analyrer  (HPA)  is  a software  package  which 
processes  the  MP L statements  and  acts  as  an  interface  between 
thn  probl<»m  definers  and  the  information  stored  as  the 
desrript  ion . 

'^rganirations  usually  reauire  that  the  documentation  of  a 
oroposed  system  include  a "system  requirement  report."  This 
-focumant  contains  a detailed  description  of  the  target  system, 
information  about  *-he  manner  in  which  the  system  interfaces  with 
th®  onaniration,  and  some  description  of  the  project  designing 
♦h**  system  including  estimates  cf  costs,  resources  required  and 
comnletjon  ♦:imp,  p*-o  . dPL  is  designed  to  state  the  type  of 
informa*-ion  which  aopears  in  the  system  requirement  report  and 
when  a problem  is  completoiv  described,  essentially  all  the 
information  for  the  system  requirement  report  is  contained  in 
tho  UPA  da*-a-base. 


^.1.  4 Intro  due*-  ion  |^o  ggl  - A Formal  System  Description  La  no  uaq^ 
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”'he  dene rin*-. ion  of  9 system  involves  describinq  "objects,"  the 
"oroper^’ies"  of  these  objects,  and  the  "relationships"  among  the 
obierts . 

Tn  fectinn  1.1.2  these  "obiects"  were  referred  to  as  "system 
description  elemon^-s"  representing  some  physical  or  conceptual 
♦•him  in  the  target  system.  Examples  of  "objects"  are  "logical 
collections"  of  data,  the  "processes"  which  define  how  the  data 
is  derived,  etc.  '‘ach  "object"  defined  in  the  target  system 
must  be  assianed  a unique  name  and  classified  by  the  "type"  of 
objort  which  it  is.  UPL,  for  example,  allows  approximately  30 
different  types  of  "objects." 

"oroperties"  of  an  "obdect"  consist  of  statements  describing 
♦ha*-  "object." 

"noi  ati  onshi  PS, " or.  the  other  hand,  describe  connections  among 
"objects."  To  say  that  object  A uses  objects  B and  C specifies 
"relation-ships"  among  these  objects.  There  are  approximately  75 
differen*-  "relationships"  that  may  be  used  in  UPL. 

An  example  of  a description  of  a (very  simple)  system  is  given 
in  Section  1.2.  A full  description  of  the  types  of  "objects" 

♦ hat  tray  be  defined  in  gpL,  their  purposes  and  usages,  is  given 
in  Section  i . ’.  The  "relationships"  allowed  in  URL  are  given  in 
gecticn  1.U  along  with  informatior.  on  how  these  relationships 
relate  to  the  overall  system  description  and  special 
considerations  involved  when  using  them. 


1 . ^ "xample 

F«>ction  illustrates  the  fundamental  concepts  of  objects, 
names  of  obiects,  types  of  objects  and  relationships  among 
obiect.s  through  the  use  of  a simple  example.  The  process  of 
comp’j tor-aided  documentation  is  also  shown.  (Properties  of 
obiects  are  not  illustrated  in  this  example.) 


1.2.1  Narrat  ivo  uesc  r intion 

•"he  following  i.s  a typical  narrative  description  of  a particular 
syst “n : 

system  called  payroll  processing  takes  employee 
information  which  comes  from  departments  and  employees  and 
produces  outputs  which  go  to  the  departments  and  employees. 
Tho  svstom  also  maintains  payroll  master  information." 

■^he  irfotmation  in  such  a narrative  description  is  usually  shown 
graphically  as  in  ’^igure  1.2.1  or  in  *'igure  1.2.2. 
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1.2.2  d en»  1 f lea t ion  of  Objects 

""ho  first  stpo  in  nsi  nq  PPL  in  to  idpotify  th<»  objects  in  the 
system  heinq  'described.  This  can  be  done  for  the  above  example 
by  underllnim  them  in  the  narrative  description: 

"A  system  can^d  oavrol  1 processing  takes  emglqYee 
inf ormat ion  which  comes  from  de part wents  apd  em plovees  and 
produces  out  out  s which  qo  to  the  depart  wen^s  ajid  em  plovees 
. The  s yst  em  also  maintains  pa vrol 1 wastep  information 
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1 . 2 . SijfSi  ^32£5  iUJ  Zl£2^ 

Fach  of  th<=  iefinotl  obiects  has  a unique  name  and  each  of  these 
ohi^cts  is  'iescribei  in  a different  context;  "employee 
information"  represents  information  passinq  from  "departments 
and  emnl cyeer;"  * q "payroll  processinq,"  "payroll  master 
information"  represents  information  manipulated  by  "payroll 
nrocessinq,"  etc.  Tn  effect,  each  of  these  oblects  represent 
different  fyDes  or  classes  of  objects.  For  example,  in  fJRL,  tha 
type  cf  obier*-  corresponding  to  that  suggested  by  "employee 
information"  is  an  IKPiJ^,  "payroll  master  information"  is  a SFT, 
etc.  ""he  following  table  relates  each  of  the  objects  defined  in 


the  narrative  description 
oh  je ct  t vp«>; 

with  a corresponding  URL  name 

an  d 

URL 

Object 

varrat  jye 

qPL  Vam€ 

payrcll  nrocessino 

payroll-processing 

PROCESS 

employee  information 

employee- in  formation 

INPUT 

teoartmepts  and  employees 

departments- and- employees 

INTER- 

FACE 

outputs 

paysystem-outpu  ts 

OUTPUT 

payroll  master  information 

payroll-master- information 

SET 

ioes  not  allow  tijants  in  the  names  of  objects;  dashes  are 
normally  used  to  connect  names  consisting  of  more  than  one  word, 
■^n  an  effort  t.o  keep  the  names  used  as  meaningful  as  possible, 
"qualified"  names  such  as  "paysystem-out  puts " (instead  of 
"o'|tDut-s")  are  encoiiraqed. 


1.2.11  Id ent  i f jca  t jon  of  Pela  tionghips 

"^he  next  step  in  usira  bFI  is  to  identify  the  relationships 
amonq  the  ahiects  which  have  been  identified.  The  relationships 
implied  in  tf,p  example  narrative  description  are  underlined: 

"8  system  called  payroll  processing  tak es  employee 
information  which  cojbps  from  departments  and  employees  and 
rrod’ices  ou*-puts  which  30  t©  the  departments  and  employees. 
The  system  also  maintains  payroll  master  information." 

■"he  followinq  relationships  have  been  identified: 


’lola  t ion  ship  Be  two^  ^ 


and 


tat  es 
come  s 
prod  uces 
qo 

maintains 


navrol 1 processirq 
emoloyeo  information 
payroll  processinq 
ou  t put  s 

payroll  processinq 


employee  information 
departments  and  employees 
ou  tPUtS 

departments  and  employees 
payroll  master  information 


■"here  are  a 


finite  number  of  relationships  that  may  be  described 
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hv  URL.  Bv  '■a'^inn  into  account  the  types  of  objects  defineil  in 
♦•h''  a^'ove  examnle  and  the  relationships  that  UPL  allows  anong 
those  objects,  the  following  ccrresponde nee  between  the 
narrative  description  relationships  and  the  UPL  relationships 
can  be  wade; 


Narrative  re la» i onsh i p yPI  relationshi n 


tav  PS 

comes 

produces 

go 

ma  inta  ins 


FECEIVES 
GENERA'''ED  BY 
GENERATES 
RFCEIVED  3Y 
UPDATES 


■"he  descrintion 
0 b 1e  c'’ 


o^  the  sysnpm  usinq 
Relation  shir 


UPL  terminology  is: 
Ob iect 


oa vrcl 1- processing 
pi  oyee-in  f orma  tion 
payrcll- processinq 
pavs  ystem-ou  t out  s 
pavrcll-  n roc  ess i ng 


PECEI VES 
G’=’NE'’A?EC  BY 
GENERATES 
PFC'’TVED  ^Y 
UPDATES 


em  ployee-infocaation 
departments-and-em  ployees 
pa  ysystem-outpu  ts 
depart  ments-and-ea  pi oyees 
pa  yroll-aaster-inf or aation 


UF I Fo r mat 

"be  object  type  of  a particular  named  object  can  be  explicitly 
defined  by  a U"!  statement.  ‘'or  the  above  example,  the 
following  upi  statements  may  he  used  to  define  the  object  type 
of  '•  payroll  nrocessinq,"  "employee  information"  and  "departments 
and  employees." 


UROCFGS 

TV  ppT 

▼ V Tvp  V ac'' 


nay  roll- processing; 

erap 1 oy ee-in  f or mat icn ; 

dep  a rtment  s-a  n d-em ployees ; 


‘'inre  ^ particular  object  may  be  involved  in  several 
relationships  the  format  for  specifying  relationships  is  made  as 
simple  as  possible.  For  any  object  defined  via  a statement 
declarim  its  object  type  (as  above)  those  relationships  the 
object  is  involved  in  may  be  listed  after  this  statement  along 
wi^h  the  corresponding  objects  in  the  relationship.  The  URL 
forma*-  *-o  specify  the  relationships  "payroll  processing"  is 
involved  in  is: 


opqr  c 

■’^c’^IVES 

np  c a'^E  s 


payroll- pro  cos  sing; 

empl cyee-in  formation ; 

pav  syst  em-ou t puts ; 

pav  rc1 1-master-in  forma  tion; 
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1.^.6  UFA 


Ono  crmpiptn  hpl  problem  s*’a  ♦•etnen*'  for  the  example  is  shown 
below,  (There  are  many  ways  in  which  all  of  fhe  information 
coul '1  be  ’^hev  are  all  equivalent  as  far  as  ORA  is 

cone etnei .) 


ro-r 

OOTPU’^ 

T T 

T.y 'Ppp?  ACE 
CENEPATFE 
prcyivES 

or  nCE.E  S 
OFOATE'^ 
PEC*”^ 
CFNFF ATE? 


omp love e-in  formation; 
pay  system-outputs ; 
pay  roll- master-information; 
flepartraent  s-an  <1- employees; 
em  pi oyee- inf ormation ; 
paysystem-ou^-puts; 
pay  roll- processing ; 

payroll- master- inf ormation; 
enp]  oyee- inf  ormation ; 
n aysys tern -out outs; 


'^nce  theso  sta^’ements  have  been  entered  into  the  OFA  data-base, 
uKA  can  he  usea  *t>  generate  a number  of  '’standard"  outputs. 
Figure  1.2.3  shows  one  of  these  outputs  called  the  POPSATTSD 
PPOPT.EE  S^ATEIENT.  This  report  contains  all  information  stored 
about  selec’-ed  obiects  in  the  data-base.  In  this  instance,  the 
reoort  has  been  generated  for  all  the  ob-jects  defined  in  the 
data-hase. 


~he  format  of  ♦■he  information  in  the  FOPKATTED  PPOBLEW  STATEHERT 
is  the  same  as  t ha+  specified  when  describing  the  example  in 
PPL.  ’’’he  report  also  nresen^’S  all  implied  relationships  as  well 
as  ♦■he  explicitly  defined  ones.  This  is  the  reason  that,  though 
only  five  relationships  were  given  in  the  example,  ten  are 
nrosented  in  th-’  ’^pKEA'tTEC  PPOBLER  STATEMENT.  To  say  that 
' nav tcll-procossina*  PECETVE?  ♦ employee- information*  implies 
that  'em Dloy ee-inf or  mat  ion*  is  ®ErEIVFD  BY  ' payroll- processing, * 
‘'tc.  '”hesf‘  are  called  complementary  statements  and  when 
dec;cribi  ng  a system  in  FIFL,  the  choice  of  which  of  the  two 
comnlementar  V relationships  to  be  used  is  arbitrary.  (The 
information  s^-ored  in  the  data-base  is  exactly  the  same.)  The 
following  are  the  complementary  relationships  used  in  the 

examnlo; 


P'^la  tionshio 


Complementary  Relationship 


nEC'IVE? 
CE’IEPATF  S 
»Ton  AT?S 


PFCEIVEC  BY 
GENEPATFD  BY 
llPfATFn  BY 


vigure  ■* . 2.  h oroserts  an  example  of  a graphical  output  that  may 
be  obtained  from  ’TA  . ""his  particular  example  shows  the 
relationships  ♦ nayrol  1- proca  ssing ' is  involved  in.  All  objects 
at®  renresentod  hv  rectangles  with  the  name  of  the  object  within 
th“  rectangle  and  'he  typp  of  the  object  is  given  on  the  top 
line  of  th*"*  rectangle. 


PAf 
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"'h«  r«»ctamlo  for  the  name  for  which  the  output  is  being 
generateil  is  placed  at  '■he  center  of  the  diagram.  All  other 
obiocts  are  placed  along  the  left  and  right  margins  if  involved 
in  "flow"  relationships,  and  along  the  top  or  bottom  margins  if 
involved  in  "strurt  ire"  or  "updating"  relationships.  The  type 
of  relationship  the  center  object  has  with  bordering  objects  is 
given  or  the  bottom  line  of  the  rectangle  for  each  of  the  border 
obdects.  Tn  the  diagram,  ' payrcll-processing ' RECEIVES 
•emnlcyee-tn  forma  tion  , ' etc.  > 

In  this  example,  names  of  objects  have  been  shown  in  lower  case 
letters  and  Tvoes  of  Objects  and  Relationship  in  upper  case 
lati-*»rs.  It  is,  therefore,  easy  to  distinguish  user  assigned 
names  for  obiocts  from  words  which  are  part  of  UPL.  The  ability 
to  distinguish  lower  and  upper  case  letters  depends  on  the 
facilities  available  in  the  installation  in  which  UFA  is  being 
used.  If  the  installation  does  not  support  lower  case  letters, 
all  words  and  names  will  appear  in  upper  case. 


1 . 3 UFl  Chiects 

A U”!.  cb  ject  is  any'-hing  given  a UPL  name  by  the  user  of 
'1*^1 /MPA.  Each  object  is  given  a unigue  name  so  i t can  be 
idertified  each  time  it  occurs  in  the  system  description. 
Conspguentlv , all  occurrences  can  be  collected  and  analysed.  A 
upL  name  is  on®  that  conforms  to  the  rules  of  name  formation  in 
the  uni,/upA  system  (Section  l.f).  Once  any  particular  object 
has  been  given  a name  it  can  be  included  in  relationships  only 
by  specifying  its  name. 

’=‘ach  obdect  must  be  a certain  object  type.  The  complete  list  of 
permissible  types  in  alphabetical  order  is  given  in  Figure  1.3.1 
together  with  th«*  allowable  abbreviations  for  each  object  type. 
Of  these,  two  are  "special"  types:  SYHONYr  and  UNDEFINED.  If 
'■he  cbiect  typn  of  an  object  is  not  declared  explicitly,  URA  may 
be  able  to  deduce  the  ohiect  type  from  the  manner  in  which  the 
object  is  used,  otherwise,  the  object  type  for  the  name  will  be 
"UNPEFT?! ’^D. " A Problem  Statement  is  not  complete  if  it  contains 
any  gNpr^'INED  names.  A SYNONYM  is  a soecial  type  of  object  that 
can  be  used  only  as  an  alias  or  pointer  to  one  other  name,  e.g,, 
an  ob^'ect  that  has  been  assigned  the  name  'validation- 
processing'  might  be  giver  synonym  'valpr.' 
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Object  Type 

Abbreviation 

AT'^niRUT” 

ATTP 

ATTn7pu-"r-  v»T,n  F 

ATTV 

CLAS’^IFTCA’^ION 

CIS 

CO  'lOI'^IOV 

coNn 

Et.EMF  VT 

EIF 

FNTT'^Y 

ENT 

PVejJT 

EVT 

GCOIIP  i 

GF 

TNPtJ’n 

INF 

tutepfacf 

INTF 

TN  TFF VAL 

INT 

KEYWO’^C 

KEY 

MA  IIBOX 

BOX 

V T?  Mp 

--- 

on  TP  TIT 

CT)T 

FLFM-nFFT'TF  ? 

pn 

PF  OCE'^  S 

FPC 

OD  PC?F  f'OP 

PPCF 

“El  i'^T’CN 

PIN 

T>^  SPfJF  CT 

RSC 

RE  ?0'I*’CS-US  AGP-PA  R A METFF 

pnt 

SPCnricy 

SEC 

SO 

SPC 

FE”- 

--- 

Srtncwrip-xjo-oPIT^PT  ON 

SSCN 

F YNCNY*' 

SYN 

S Y 5 T - P A P A P 

FYSF 

?n  ACF- KEY 

■^KEY 

UU  f'EFINFD 

— 

‘'.3.1  Object  Types  and  Abbreviations 


■’.3.1  Classification  of  Object  Types 

"■or  ease  of  iescribinq  the  purpose  and  characteristics  of  each 
♦■ynt>  objec*-  wi»-h  resoec*-  to  the  system  documentation,  it  is 
convenient-  *0  qro'in  the  types  into  classes.  fha  list  of  classes 
and  object  ypen  vithin  each  class  if  shown  in  ''iqure  1.3.2.  It 
wist  he  emphasized  that  classification  is  for  exposition  only 
and  plavs  no  role  in  the  formal  syntax  or  semantics  of  The 

maloc  cateqories  of  classification  are  the  following: 

'^roanitatiop  for  objects  used  to  describe  the 

organization  or  environment  in  which  the 
target  system  is  to  operate. 

""arget  Svs‘-em  for  objects  used  to  describe  the  target 

syst  em . 
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’’roipc*  M^nanjuent  for  obiect's  used  to  describe  the  project 

developinq  the  tarqet  system. 

Proner^ies  for  objects  used  to  describe  the  objects 

in  the  above  three  categories. 

The  purpose  and  characteristics  of  each  object  type  is  described 
below  in  tho  order  in  which  listed  in  Figure  1.3.2.  The 
relationships  in  which  an  object  of  a given  type  can  be  included 
is  outlined  in  Section  1.4,  and  given  in  more  detail  in  Sections 
? and  ■» . (""he  precise  syntax  is  given  in  the  "User  Pegu  irements 

Language,  Language  Reference  Manual.”*)  A discussion  of  the  role 
of  each  object  type  and  situations  in  the  system  description 
process  wh»thor  it  should  or  should  not  be  used  is  given  in 
"^ect  ion  4. 


1 . * . 2 0rgani7a*ion  Objects 

Th''  UP!  object  used  to  describe  some  part  of  the  organization  or 
en  vi  con  IT  en’’  with  which  the  target  system  interacts  is  called  an 
TN"'fnFAC’='  (or  M - w OPLD- FNT  IT  y)  . INTFPPACFS  are  often  used  to 

describe  departments  in  an  organization  or  other  information 
processing  systems  which  interface  with  the  target  system. 
Interfaces  are  sometimes  called  by  such  names  as  "stations," 
"organizational  units,"  etc.,  in  other  documentation  systems. 

Interfaces  are  objects  which,  as  far  as  the  target  system  being 
deyolcped,  mav  receive  data  frcm  it  or  transmit  data  to  it.  For 
"xample,  if  a warehouse  stock  control  system  were  being 
d-^signed,  interfaces  might  be  suppliers,  customers,  the 
accounting  department,  etc.  Thev  are  not  part  of  the  target 
system,  but  have  important  relationships  with  it.  Though  the 
functions  of  an  interface  may  be  complex,  only  the  description 
pertaining  to  its  relationships  with  the  target  system  are  of 
importance.  T^.terfaces  should  be  described  if  they  generate 
information  to  the  target  system,  receive  information  from  the 
target  svs*’em,  or  are  responsible  for  information  within  the 
♦•arget  system. 

* Pact  II  of  this  document 
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Ilf  If  object  types 


TVJ-CPFIVCV'^  0?  orTAv:7  a"'TONAL  'INITS  INTEPFACE  (REAL- 

WORLD-ENTITY) 


CniIFC''IONS  OF  INFORMATION 
(FXTF®N  AL) 

(TF'''EPN  AL) 

INPUT 

OUTPUT 

ENTTY 

COT  lEC'^'^nvp  OF  TNFORFATION  INS'^'ANCIS 

SET 

F?I  ATICNSHIPS  A'rONO  COLLECTION  OF 
’’N  FO^r  ATTON 

RELATION 

OA’^A  PF'TNI'^TON 

GROUP 

ELEMENT 

OATA  DEPIVA"'TON 

PPOCESS 

S''’F.r  Avr  voi,nwF 

SYSTEM-PARAHETEP 

INTEPVAL 

'^YVAMIC  BFUAYTOr 

EVENT 

CONDITION 

SYSTEM  AFCPITFC^tip  F 

PROCESSOR 
RESOURCE 
PESOURCE- 
USAGE-PAPAH  STEP 
UNIT 

pPOOFc"  MAVAOE*'’^NT 

PROBLEM-DEFINFP 

MAILBOX 

pp^O  FC-rj  FS 

SYNONYM 

KEYHOPD 

ATTRIBUTE 
ATTRIBUTE- VA  LUE 
CLASSIFICATION 
M^MO 

SOURCE 

SECURITY 

TRACE-KEY 

O’-T’^F 

UNDEFINED 

*’iqaro  1.3.2  Classification  of  Ob-ject  Types 
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1.3.3  Ta £321  liSlSE  Ohjec ts 

'^ane*-  sys^-^m  ob-jects  are  us^^d  describe  the  target  systen 
with  respect  to  forms  of  inf  or ma ticn , processing  of  the 
information,  behavior  of  <-he  system  over  time,  etc. 


■’.3.3.1  Coll  ions  of  I r for  ma  t ion 

Information  related  +c,  or  pertaining  to,  one  particular  type  of 
thine  or  concep*-  is  •►hought  of  as  a collection  of  information, 
’'or  examrle,  "emnlovee  i nf  or  ma  t ion  ” may  be  a collection  of  all 
information  nertairing  *•  o a particular  employee.  This 
information  would  be  derived  when  an  employee  is  hired  by  the 
company,  used  ♦'o  produce  paychecks  for  the  employee,  updated  to 
reflect  changes  in  f h e employee's  status,  address,  etc.  The 
collection  is  to  be  thought  of  as  a whole  (in  the  above  example, 
everything  that  had  to  be  known  about  an  employee)  though  in 
beina  nrocer.sad  bv  ♦■he  target  system,  only  portions  of  the 
collection  might  be  used  at  any  one  time.  There  are  three  types 
of  collections  of  information  that  may  be  defined  in  gPL : 

TVPin?,  ^nd  FNTiTIPr.  The  difference  among  these  types 

of  collections  is  related  to  their  rcle  in  the  target  system. 


IILZIII- 

An  ■♦Kpg"'  is  a eolloction  of  information  produced  external  to  the 
target  system,  but  used  by  the  tgrqet  systein.  For  example,  in 
an  inventory  svstem,  a customer  order  may  be  considered  an  INPUT 
to  the  s vst  e m . 


OU'^nn't  g 


An  nuTP’T'^'  is  a collection  of  information  produced  by  the  target 
system,  hu*"  which  is  used  external  to  the  system.  For  example, 
the  pavchecks  produced  by  a payroll  processing  system  could  be 
thought  of  as  OUTPhTF  as  they  are  eventually  used  by  employees 
outside  of  the  system.  Once  the  collection  has  left  the  system, 
no  further  reference  may  be  made  to  it. 


FM  TI T 


An  FNIItY  is  a collection  of  information  which  is  maintained 
internal  to  t h®  system.  FN"'ITIEF  are  initially  "produced"  and 
then  "maintained"  usin<)  information  from  INPUTS  and  then  OUTPUTS 
are  produced  using  information  from  ENTITIES.  The  "employee 
information"  described  above  in  the  definition  of  "Collections 
of  Information"  is  an  example  of  an  ENTITY. 

All  of  the  above  typps  of  collections  of  information  may  belong 
to  larger  collections  and  may  be  broken  down  into  smaller  units 
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1 


of  information.  Consequently,  there  may  be 
r^la ti on  shins  between  particular  obiects  of 


"structural" 
these  types. 


1.1. 3.2  Collections  of  Information  Instances 

A number  of  instances  of  one  or  more  collections  of  information 
is  calleil  a SFT.  ’='or  example,  a SET  miaht  be  defined  to 
describe  all  instarces  of  "emplcyee  information'*  in  the  tarqet 
system.  There  is  an  imoortant  distinction  to  be  made  between  a 
collection  of  information  and  an  instance  of  this.  Information 
called  "emnloyeo  information"  is  a collection  of  information, 
but  eiTDloyee  information  about  .TACK  SKITH  is  an  instance  of  the 
collection  of  information.  A number  of  instances  together  may 
constitijte  a ST"  of  "employee  information."  Likewise,  if  two 
collections  of  employee  information  were  maintained  (one  for 
current  omnlovees  and  one  for  retired  employees)  a SET  could  be 
defined  to  contain  instances  of  both  collections  as  well  as 
defininq  a separate  SET  for  each  ccllection  of  information  about 
th“  different  types  of  employees. 

""he  common  example  of  a SET  is  a master  file  consisting  of 
records,  i.  e . , r’l^ITTES,  for  each  emcloyee.  However,  SET  may 
also  consist  of  T'JPU'^S  and  OfJTPOTS.  This  permits  SETS  to 
ropresent  collections  of  INPUTS,  e.g.,  queues  of  messages  to  be 
processed . 


1.1.  3.3  A mom  Collections  of  Info(rmati,on 

Collections  of  information  maintained  internal  to  the  system 
{EV^I^irs)  are  often  "related"  to  each  other  in  that  there  is 
intotmation  which  is  not  inherent  to  either  yet  is  associated 
with  bo*-h.  In  the  example  of  a warehouse  stock  control  system, 
informa*’ion  about  inventory  items  may  be  related  to  information 
about  their  suppliers,  etc.  RELATIONS  are  used  to  describe 
logical  connections  among  ENTITIES. 


I.'^.l.g  Data  Def  init  ion 

Collections  of  information  (INPUTS,  OUTPUTS  and  ENTITIES) 
"contain"  values  of  information  called  ELEMENTS  and  GROUPS. 


ELTM 

''L**EEN'"‘^  are  the  basic  unit  of  information  and,  therefore, 
cannot  be  subiividcd.  An  ELEMENT  is  used  to  describe  a data 
oblect  which  may  take  on  a value.  For  example,  if  "employee 
information"  was  defined  to  be  an  ENTITY  it  would  not,  in 
itself,  have  a value.  '^he  ELEMENTS  making  up  "employee 
information"  such  as  "age,"  "sex,"  "salary,"  etc,,  might  have 
values  for  a particular  instance  of  "employee  information," 
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flPOUFS 

GPonPS  arp  to  'iescrite  a collection  of  HLEMENTS  and/or 

o*-h«r  GPOUPR.  r.ROUPF  allow  the  prohlen  definer  to  loqisally 
relate  one  or  more  FTEr^NTS  and/or  GROUPS  toqet.her  and  refer  to 
them  collectively  I’V  the  qPOUP  name. 

qpqnp?  can  be  ♦•hough  t to  be  synonymous  with  the  names  of  the 
onoTjo's  components.  In  the  example  of  "employee  information," 
the  "name"  of  ♦•he  employee  may  he  defined  as  a "POUP  where  the 
constitutonts  of  the  qpoup,  "first  name,"  "middle  initial," 
"surname"  may  be  defined  as  ELEMENT*.  The  use  of  GPODPS  is 
primarily  a rotational  convenience. 


1.1.3.S  Eat  a Cerivation 

An  information  processing  system  exists  to  process  data,  i .e , , 

*■0  produce  data  values  from  other  data  values.  This 
transformation  is  known  by  different  names  such  as  process, 
procedure,  func‘-ion,  operation  activity,  etc.  In  URL,  a PROCESS 
is  the  type  of  ob-ject  used  to  describe  this  transformation. 

The  ‘otal  ♦•arqet  system  can  be  regarded  as  a PROCESS  at  the 
highest  level.  A PFOCe^s  is  defined  by  specifying  the 
information  upon  which  it  operates  and  the  information  which  it 
prod  uce  s . 


1.3.3.R  Sire  and  Volume 

obiects  which  relate  information  pertaining  to  the  amount  of 
information  maintained  by  the  system  and  volume  of  information 
to  be  processed  are  described  to  estimate  the  size  of  the  target 
syst  em . 

Information  about  the  size  of  a proposed  target  system  is 
usually  staged  in  terms  of  numbers.  E.q.,  SOO  employee  changes 
occur  each  pav  period  or  production  analysis  report  consists  of 
lOT  panes. 

In  U*I,  the  "parameters"  affecting  the  size  of  the  system  are 
considered  ob-j<?cts  and  each  given  a unique  name;  two  types  of 
obiectn  are  p^^r minted; 

SYS'^’P^-PAFAf'ETERS  and  time  INrERVALS 

“"he  basic  purpose  of  treating  these  parameters  as  obiects  is 
that  each  occurr®r.cP  can  he  uniquely  identified.  Consequently, 
al  1 occurrences  can  be  identified.  Also,  only  one  assignm^it  of 
numerical  values  need  be  ready,  the  assignment  can  be  as  "late" 
as  possible,  and  sensitivity-analysis  can  he  carried  out. 
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SYS  I liJzP  ifl!!  Ills 

A SY  STF^'-PA  F A '*ET??  is  uspcl  to  repres«»nt  a value  relevant  to 
characterizin'!  ’'sys*-em”  sire,  A SY5TSM-PARAMETER  may  be  used  to 
iescribr  the  number  of  instances  of  a particular  ELEMENT  in  a 
particular  instance  of  an  ENTITY,  for  example. 


TN"’FFVAL 


An  INr^DVAL  is  Use'S  to  describe  a unit  of  time.  In  defining 
freauencv  of  an  occurrence  in  the  system,  the  frequency  must  be 
defined  with  respect  to  seme  unit  of  time.  A "year”  is  an 
example  of  an  interval,  as  is  "vork  veek." 


l.l.i.T  Dynam  ic  leha  v ior 

■"he  descrintior.  of  the  dynamic  behavior  of  the  system  indicates 
raou i rements  on  prooessinq  order  and  the  relationships  between 
processes  and  obiects  that  initiate,  terminate,  or  interrupt 
them  . 


An  is  used  to  describe  possible  occurrences  during  the 

operation  of  the  target  system.  An  occurrence  of  an  EVENT  is 
associated  with  a SDocific  point  in  time,  but  the  same  EVENT  may 
occur  mor-^  *-han  orre  during  target  system  operation.  For 
“xample,  "error  recognized"  may  be  an  EVENT  that  causes  normal 
processim  to  be  suspended  while  an  error  processor  is 
initiated. 


cnt'DiTirN 


A CONrT"'’’ON  is  used  to  describe  some  aspect  of  the  state  of  the 
targe*  svs*em.  A CONDITION  may  be  either  true  or  false.  For 
example,  "input  da*a  valid"  could  be  a CONDITION.  A change  of 
this  condition  from  true  to  false  might  cause  an  EVENT  (such  as 
"error  recognized")  or  might  directly  initiate  error  processing. 


1.3.  i.P  llStem  A rch i t ect u re  Objects 


poQC ' ESC " 

An  object  tha*  can  "perform"  a IFOCESS  is  a PROCESSOR,  In  other 
words,  a npor'=’FFOP  is  an  "aaent"  that  physically  acts  to  perform 
a PpecESS.  A compu*er  system,  a department  in  an  organization, 
a person,  can  all  bs  modeled  as  a FFOCESSOP. 
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"h®  total  tarqo^  system  can  be  reqaEfled  as  beinq  perforied  by  a 
sinqle  PPOCES^OP  at  the  hiqhest  level.  This  hiqhest  level 
PROCFF*'np  is  the  collection  of  all  the  physical  entities 
(inclndina  huaan  beings)  that  actually  carries  out  all  the 
inforvation  processing  functions  in  the  system. 


PESPrJFCF 

A ^?SC'!Pr’=’  is  something  ^ hat  the  physical  elements  in  the  target 
system  consume  in  order  to  carry  out  information  processing 
functions.  A FESOnpcF  is  con suiiied  , and  once  an  amount  of 
"'•sc T’FC’='  is  consumed,  it  is  considered  unrecoverable  because  it 
is  "used  UD. " For  example,  a certain  amount  of  PESOOPCE  called 
electricity  is  consumed  by  an  electrical  appliance  in  a given 
time  period.  Th®  amount  of  electricity  thus  consumed  is  not 
recoverable  because  it  is  used  up. 

is  important  to  note  this  somewhat  specialised  meaning  of 
RFSCnFCF.  Tn  the  general  usage  of  the  term,  "resource"  could 
mean  something  that  is  needed  for  a task  to  be  performed,  but 
which  is  returned  after  i is  finished.  For  example,  an 
electrical  appliance  can  be  regarded  as  a resource  in  this 
sense:  when  it  is  being  used  by  someone,  nobody  else  can  use  it; 
bu^-  when  it  is  no  longer  used,  it  is  available  for  use.  In  ORL 
♦•his  second  meaning  of  "resource"  is  modeled  by  PHOCESSOH,  and 
the  term  RFSonPCE  is  exclusively  used  for  the  first  meaning. 


Since  it  is  necessary  to  handle  quantities  of  RESOURCES,  units 
are  ppeded  to  measure  FFFOnfCEs.  The  ob  "ject  UNIT  is  used  for 
this  purpose.  ^ nv^T  is  used  to  measure  PESOURCFs.  For 
examcle,  electrici*-y  may  be  measured  in  a UNIT  called 
"kilowatt-hour. " 


°ESO  UFCE-USAGF-Pa  PAF  ET’='P 

A R E SCU’^CT-gS  A'^F-PAR  A HETE  F is  an  ob'ject  that  defines  a measure 
of  the  r*'SnTtTJ(;p  usage  for  a PPCCESE,  It  is  introduced  in  UPL  as 
a wav  of  expressing  resource  consumption  of  a PROCESSOP 
perFotming  a pooc^'ES  independent  of  what  PROCESSOR  performs  it, 

’or  example,  one  can  assign  values  for  a FESOURCE-US AGE- 
PAPAMF'tF’  "no-o^-for t ran-steps"  to  a set  of  PPOCSSSes.  The 
values  oF  the  ^FsnnPCE-MSAGE-PARAFETER  for  a PROCESS  might 
signify  the  number  of  FnPTP»S  steps  if  the  PROCESS  is  tp  he 
performed  by  a computer  and  FORTFAN  is  to  be  used  to  write  the 
program,  ""he  actual  amount  of  RPSCU5CS  consumed  in  order  to 
carry  out  this  p’OCESS  depends  on  the  particular  PROCESSOR'S 
ability,  which  is  expressed  in  terms  of  PESOURCB  consumption  per 
pmcngfCE-ns  AGE-F  A’ANETE’, 


PA®r  T nSEF  PEQUIPEFENTS  LANGUAGE  MANUAL 


1 P-'/rniTICS/^RL  nSFR'S  MANUAL 


21 


1.’.4  Prolec t £!2j5£if 

''r'liec^:  nanaqement  ohiects  are  used  to  provide  inforiation  about 
♦rhe  individual  writinq  th^  URL  description  of  the  target  system. 
PPL  is  not  intended  ♦o  be  a proiect  managenent  system,  but  it 
provides  for  two  types  of  obiects. 


PPOPT '*■*- 0 pFT  N FP  is  an  obiect  used  to  describe  a person  who 
writes  the  nroblam  s^’atement  (UFI  statements)  for  the  target 
svstoiti  or  who  has  the  responsibility  of  maintaining  the  UPL 
descriptions  for  ore  or  more  other  UPL  obiects.  For  example, 
PROP  T.  P'1- PEF'^NFP,  ".lane  Smith,”  may  be  responsible  for  the  URL 
description  of  the  obiects,  "employee  information,"  "payroll 
nrocessi  r.q,  ” etc.,  while  other  people  on  the  project  may  be 
r“snonsible  for  oth»r  obiects  in  the  target  system's 
desc r i pt  ion . 


1ATLBCX 

S rATIPOy  is  us“d  ♦’O  describe  the  location  where  questions 
and/or  information  about  the  UPl  description  of  a particular 
target  system  may  tp  sent.  Usually  a MAILBOX  is  related  to  a 
P^OB  LFF-  r>’^'’TNFP . 


1 . 1 . S Proper t V Objects 

For  an  accurate  description  of  a tarqet  system,  special 
properties  of  certain  obiects  must  be  defined.  For  example,  in 
describinq  a larqe  information  processing  system,  it  may  be 
noceceary  to  define  which  functions  (PFOCESSES)  are  to  be  done 
manuallv,  run  batch,  or  on-line,  etc.  The  URL  object  types  that 
are  available  are  SYK’OKYF,  KFYWOFO,  ATTRIBUTE,  ATTRIBUTE-VALUE, 
CLARSIFTCA’^ION,  MEMO,  SOnncE,  SECURITY  and  T PACE-KEY . 


^YVO NYM 

A '•YUCNYM  is  used  to  define  an  alternative  name  (alias)  for  a 
qiven  name  in  the  UPL  description  of  the  system.  The  SYNONTN 
may  simply  define  an  abbreviation  of  a long  name  or  specify  a 
totally  different  nime  for  an  object,  depending  on  who  looks  at 
the  obiect  fi.e.,  several  people  may  think  of  the  same  thing, 
but  rail  several  different  names)  . 


FFYwnpp 

A KFYHOFP  is  an  object  type  used  to  identify  one  or  more  objects 
in  the  tarqet  system  description  for  selection  and  analysis 
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purnosps.  '•or  pxamplp,  if  all  functions  (PpocKSSES)  described 
as  heirq  manual  procedures  in  the  tatiet  system  were  to  be 
listed  and  analyied  toqether,  the  KEYMOPD  ’’manual"  could  be 
a*-tachpd  to  each  PPOCESS  for  this  purpose. 


lIZ£I£I21f  2!ii2  iIIfI2UZ!^rVALnK 

ATTPTPn-FS  ani  A T'’'P  I BD'^E- VAL  ns  s arc  used  ’’o  describe 
charac’-erist  ics  of  particular  obiects  in  the  target  system 
description  that  mav  not  he  described  by  any  other  UPL 
s’-atements.  *or  example,  to  describe  that  the  length  of  an 
FLESF*’"*  is  six  characters  long,  the  ATTRIBBTF  "length"  could  he 
defined  and,  for  a particular  ElEf’ENT,  the  corresponding 
A'’"'’’PTpn"’F-VAinE  could  he  "6." 


CLi2SIII£AZ:i£Ii 

n A sgjFjcATrOM  fay  hr  associated  with  data  ob-jects,  PPOCTBSSES 
and  FFCCEBSopg  in  the  taroet  system.  A value  may  also  be 
associated  with  the  C lASSIFICATTCN . In  order  for  a PROCESS  or 
pr>oci?<;?cP  to  he  allowed  access  in  the  target  system  to  a data 
obiect,  it  Ulus’-  have  all  the  CLASSIFICATIONS  that  ate  associated 
with  the  '^a*- a object,  and  the  value  must  be  greater  than  or 
equal  *-0  the  value  associated  with  the  data  object. 


A f’EdO  is  used  to  describe  a note  (text)  relevant  to  some  aspect 
of  ♦he  ♦■arqet  system  desctiotion.  For  example,  a note 
roncernirq  unresolved  problems  in  describing  a select  number  of 
oponns  in  the  target  system  description  could  be  defined  as  a 
N5''r>  and  then  related  to  each  of  the  appropriate  GPOBPS. 


so  rtncF 

A sogpc’'  is  used  to  describe  an  object,  outside  of  the  problem 
statement,  relevant  to  the  description  of  one  or  more  objects  in 
the  tarqer  system  description.  For  example,  a feasibility  study 
of  the  target  svstnm  being  designed  may  have  information 
relevant  to  why  one  alternative  of  describing  the  target  system 
was  chosen  over  another.  The  feasibility  study  could  be 
designated  as  an  object  of  type  SOOPCE. 


5EcgFT'"Y  is  used  to  identify  what  object  descriptions  can  be 
reviewed  by  a given  class  of  persons.  Some  types  of  information 
maintained  by  the  *arqet  system  may  be  considered  confidential, 
so  thp  description  in  the  problem  statement  on  how  this 
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information  is  maintained  may  be  restricted  to  high  level 
manaqement  and  a few  select  programmers. 


'•’PACF-Kf  Y 

A T^'ACF-VEY  is  used  to  correlate  oblects  vhich  exist  in 
different  data-bases.  ’'or  example,  the  logical  system  design 
and  physical  svstem  design  of  a security  control  system  may 
°xist  in  two  different  data-bases.  An  obdect  called  a security 
level  mav  eris*-  in  the  logical  design  data-base,  and  a field  of 
numbers  called  a security  level  number  may  exist  in  the  physical 
design  data-base.  A TPACF-KEY  called  a security  level  key  may 
be  applied  ’•o  both  obiects  to  display  the  correlation  between 
them  . 


d . 4 URL  Fela  t ion  ships 

""he  previous  section  presented  the  types  of  objects  that  must  he 
defined  when  describing  an  information  processing  system, 
•^rqaniza^-ion  objects  define  the  environment  in  which  ths  target 
system  is  embedded,  "arget  System  objects  describe  the 
components  of  the  target  system.  Project  Management  objects 
describe  the  projcr:’-  in  which  the  target  system  is  being 
developed,  and  Property  objects  describe  properties  of  all  types 
of  obiects. 

Tn  addition  to  identifying  particular  objects  (by  giving  them 
name?),  the  relationships  among  these  objects  must  be  stated. 

For  =»xample,  if  "erap  loyee-information"  is  defined  to  be  an  IHPOT 
and  ''pavroll-processi  nq"  as  a PROCESS,  a relationship  connecting 
these  two  objects  may  be  specified.  In  UFL  terminology,  if 
"^mp  lovee-in  format  ion '•  is  an  input  to  "payroll-processing,"  the 
relationship  car  be  stated  "payroll-processing"  RECEIVES 
"emnlovee-i n f orm ation " or  "employee- informat  ion"  is  RECEIVED  by 
"pa V r ell -processing. " 

Figure  ‘*.4.1  orosent?  a listing  of  all  relationships  allowed  in 
in  a Ipha be* i cal  order  along  with  legal  abbreviations  for 
♦■hesp  St atpment s . (A  dash  in  place  of  an  abbreviation 
designates  that  *here  is  no  acceptable  abbreviation  for  that 
sta  * emen  f .)  ’’’his  section  gives  an  introduction  to  the 
TPla  ion  Shi  PS . '’'hev  are  defined  in  detail  in  Section  2 and  3. 


1.4.1  Cornlementarity 

One  char  ac*er  ist  ic  of  mgs’-  rpla  tionships  between  two  names  is 
that  i*  mav  be  specified  in  both  directions.  Roc  example, 
specifying  ’•ha*  an  dHTPHT  is  GENERATED  by  a PROCESS  is 
equivalrn*  to  specifying  that  the  PROCESS  GENERATES  the  OOTPOT. 

an,)  GRvi:rA''’ES  are  called  complementary  relationships. 
’'Iqure  1.4.2  presents  a list  of  all  complementary  relationship 


PART  T 'TER  R TREMSN"'S  LANGUAGE  MANUAL 


1. 


HP1  PO/?inLTICS/D?L  nSSF'S  24 


Dairs.  (A  iash  designates  that  ♦■he  relationship  does  not  have  a 
comp  lement. . ) 

1.4.2  "Plati  2I!5hlrS  f.£iJf£fD  Pi f f erent  Classes  of  Objects 

allows  a n'lmher  of  relationships  to  "connect"  objects 
whether  they  are  of  the  same  class  as  defined  in  Section  1.3  or 
in  different  classes.  ^or  instance,  in  the  above  example,  two 
"arget  Sys’-em  objects  were  related  via  the  RECEIVES 
relationship.  Since  Orqanization  objects.  Project  Hanagement, 
and  Ptoperfv  objec^-s  also  contribute  to  the  description  of  the 
system,  they,  ♦■oo,  must  b®  related  to  defined  Target  System 
objects.  Therefore,  there  is  another  set  of  relationships  to 
connect  Target  ‘System  objects  with  Organization  objects,  another 
for  Target  System  objects  and  Property  objects,  etc.  The 
possiHr  sets  of  relationships  are  shown  in  Figure  1.4,3. 

♦’ela  t ion  ships  may  b'^  classified  in  the  same  way  as  objects  were 
classified  in  Section  1,3.  The  first  row  of  Figure  1.4,3 
presents  relationships  that  an  Organization  object  may  have  with 
other  Organization  objects,  with  Target  System  objects.  Project 
lan.agement  objects  and  Property  objects.  The  second  row 
presents  relationships  that  a Target  System  object  may  have  with 
Organization  objects,  other  Target  System  objects.  Project 
"Management  objecM-s  and  Property  objects.  The  third  row  presents 
roia tion shi  PS  that  a Project  "lanagement  object  may  have  with 
Organization  objects,  "'arqet  System  objects,  other  Project 
Tanagemept  objects,  and  Property  objects.  The  fourth  row  in 
Pigure  1,4,3  presents  relationships  that  a Property  object  may 
have  with  Organization  objects.  Target  System  objects.  Project 
lanagewen"’  objects  and  other  Property  objects. 
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Abh  re- 

Abbr  e- 

•^olatjop  ship 

viation 

Pe 1 At  ion ship 

viation 

APPLIES 

APP 

PPOCECUPE 

PRCD 

AS  1 F PT 

ASP? 

'5ECET  VED 

RCVD 

ASSOCTA'^FD 

A SOC 

RECEIVES 

RCVS 

ASSnciATEn-OATA 

A SOD 

DELATED 

PEL 

TpOTpj; 

A TTR 

pesoopce-osage 

RU 

RF'^WEEN 

PT«N 

PESOOPCF-USAGE-PAPAMETER- VALUE 

ROPV 

CAOPTNALITY 

CAPO 

PKSPCNSIfiLE 

RESP 

CAPS  FC 

CST> 

PF SPON SI  EL E- INTERFACE 

PINT 

CAUSES 

CSS 

?F  SPONSIBLE-PPOBLEM-DEFINER 

RPO 

CLA'J  SIPTCA'^IOW 

CIS 

SFCMEITY 

SEC 

COVN^CTI  VT'^Y 

CONN 

SE CUEITY- ACCESS-RIGHTS 

SAR 

COTS  TS'"S 

CSTS 

SFE-HEMC 

S« 

cnvs  o'^F'' 

CNSD 

SOURCE 

SRC 

COMP  rj>1FS 

CNSS 

sn  BPAPTS 

SUSP 

COVTAINFP 

CNTP 

SUDSFT 

SST 

nFPrVATTCN 

OPVN 

SUBSETS 

SSTS 

n’=‘P  I V2D 

rPVD 

SURSETTING-CFITEPIA 

SSCA 

n^FT  VPS 

OP  VS 

SUB SETTING-CRITERION 

SSCN 

DSSO  TsipT^nT 

PESC 

SYNONYF 

SYN 

o^v?  FA'^r  r 

G^ND 

TEPMINA’^ED 

TRMD 

GF’IF  FATFS 

GENS 

TERMINATES 

TRMS 

TARPONS 

MAP 

■OERMINATION 

TERH 

■^PFF  'PIFT  FP 

IDD 

TFPMINATICN-CAUSES 

TERC 

TPSNTIPTES 

IDS 

TRIGGEPFC 

TRGD 

Trjr-poTxcN 

I NCP 

TPIGGEPS 

TRGS 

TVCF  PTirN-CAMSi^S 

INCC 

UPDATED 

UPOD 

TN'^t  F P n’’TP'P 

I N'^D 

UPDATES 

UPDS 

T «}TP  r Fnr'7s 

TN'OS 

USED 

-- 

KFYWOPP 

KEY 

US'=’S 

-- 

•'A  OP 

-- 

UTILIZED 

UTLD 

•«Hwr  c 

KAf 

U'oiLIZES 

UTLS 

•'ATI  PCX 

POX 

VALUES 

VAL 

TA  IT  T AIK  pp 

FNTD 

VOLATILITY 

VOL 

r Aiv^ArNs 

KN"'S 

VOLATILTTY-MEM  BEP 

VOLK 

wFASOpPO 

FSPD 

VOLATILITY-SET 

VOLS 

TF  AS  IIPFS 

KSPS 

WHILE 

RHL 

OAP*" 

-• 

PEPFCFMED 

pprn 

PFppoF^r 

pprs 

oirjurp  1.4.1 

List  of  'JPL  S'-.a 

bpifl®  n ts 

in  Alphabetical  Order  with  Abbreviations 
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wplationshrp 

A';-'!EPT 

A'i'^OCTA'^ED 

/I  TTp  jpri"’e;s 

rAoCTNAlT'"Y 

CAUSED 

CONNECT!  VI'"Y 

Cf'NE 

CONT  ATNFD 

DEPT  VET 

CEV''PA"’FC 

HAPPENS 

TDFN"'IFIFD 

TNCT  PTI^  N 

TN’^FFFMPTED 

HEYWOpn 

MADF 

MAILBOX 

NAI>!"’»rNFD 

NFASnPFD 

PAPT 

nVB  POP'*'?  D 

ot-cptvfD 

PFLA  TFP 

PF’50nFCE-'l*' AGE 

PES'»CNSr«L'’-  INTEPPACF 

P’'S’'CNSI  RLE-PRORLFr-PFF'^NFP 

S'^CUPITY 

SEE-  '♦EHn 

SOrjPCF 

HriB'  FI 

SETTING- CP  T'^EEIA 
‘^YNC  NYM 
TERM  TN»'^ED 

■»«POV  T^H-TQfJ 

•"SAC  ?-K»Y 
"’PTGGTPFD 
HPDATFP 
HSEn 

H'^ILTFEr 

VALUES 


CoBPlenentar V Relationsh 4p 


ASSOCTATEP-nATA 


CAUSES 

CONSOflES 

CONSISTS 

DERIVES 

GFNFRATES 

ICFNTIFIES 

INCEPTION-CAUSES 

INTERRUPTFS 

APPLIES 

MAKES 

APPLIES 

MAINTAINS 

MEASURES 

SUEPAR'^S 

PEFFCRHS 

RECEIVES 

BETWEEN 

RFSOUPCE-nSAGF-P A FAME TER- VALUE 

FFSFONSIBLE 

RESPONSIBLE 

APPLIES 

APPLIES 

APPLIES 

SUBSETS 

SUBSETTING-CRITERION 

DESIGNATE 

TERMINATES 

TFPMINATION-CAUSES 

APPLIES 

TPIGGERS 

UPDATES 

USES 

UTILIZFS 


Piqure  1.4,2 

List  of  all  URL  Relationships  with  Complementary  Relationships 
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ORGANIZATION  CEJFCTS 

TARGET  SYSTEM 

OBJEgTS 

O^GANTZATION 

^BUECIS 

Sf^BPAFTS/PART 

GENERATES 

RESPONSIBLE 

RECEIVES 

"A’SGE'" 

GEN’^RA'^ED 

ASSOCIATED/ 

ASSOCIATED-DATA 

or f r ry  op 

CAPDINALI'^Y 

OBJECTS 

RESPONSIBLE- INTER  FACE 

CAUSED/CAUSES 

CLASSIFICATION 

CONNECTIVITY 

CONSUMED/CONSUMBS 

CONTAIN ED/CONSISTS 

DERIVED /DERI VES 

GENERATFD/GENERATES 

HAPPENS 

IDENTIFIED/IDENTIFIES 

INCEPTION/ 

INCEPTION-CAUSES 

INTEPPUPTED/TNTERPUPTS 

MADE/MAKES 

MAINTAINED/MAINTAINS 
M^'ASURED/MEASDRES 
PART/SUBPART 
PERFORMED/PERF3RHS 
BECEIVED/PECEIV  ES 
FELATED/RELATES 
RESOUPCE-US AGE/ 
PESOURCE-USAGE- 
*>A  PA  METER- VALUE 
SSCURITY-A3CESS-RIGHTS 
SUBS  ST/SUBSETS 

subsetting-cpiteria / 

SURSETTING-CR ITER  ION 
TER  MINA  ted/terminates 
"ERMINATION/ 

TERMINATICN-C  Atl SES 
TRIGGER  ED/TRIGG  EPS 
UPDATED/UPDATES 
nTILI7ED/nriLIZ  SS 
VALUES 


PPO.T  EC"’ 

PFS  PONSTBLE 

RESPONSIBLE 

SANA  GFMEN'^ 

OBJECT'’ 

rPOPEF"‘Y 

OBJECTS 

APPI  IFS 

APPLIES 

’'iTir»»  1.U.3  F pla  t ion  shi  ps  among  Classes  of  Objects 
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PROJECT  XANAGEEENT  OBJECTS 

PROPERTY  OBJECTS 

ORGANIZA'''nN 

OBTFCT'^ 

PFSPONSTRLE-PPOBLEM-DEFTNEP 

ATTRIBUTES 

KEYWORDS 

SECURITY 

SEE-MEMO 

SOURCE 

SYNONYM 

TRACE-KEY 

SVSTf* 

OBJ^’CTS 

T??S  PON5T  BLE-PPORLRM-DEFINER 

ATTRIBUTES 

KEYWORDS 

SECURITY 

SEE-MEMO 

SOURCE 

SYNONYM 

TRACE-KEY 

'’SOJFCT 

1AVAGEMFN"’ 

OBJECTS 

NAI LBOT/APPLIES 

ATTRIBUTES 

KEYWORDS 

SECURITY 

SEE-MEMO 

SOURCE 

SYNONYM 

TRACE- KEY 

PPOP  ?^TY 
nnjFCTS 

APPT  T'^S 

ATTRIBUTES 

KF.  YWORDS/APPLIES 
SECURITY/APPLISS 
SEE-MEMO/APPLIES 
SOURCE/AP  PL lES 
SYNONYM 

TRACE-KEY 

r iqiir»? 

1.4,3  Fela '•  ion  Shi  Es  among  Classes  of  Objects 
(Continued) 
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1 . 4 . ? Na rr^it  iv^  an^  Text  Description 

Anv  informa*- ion  which  is  needed  to  describe  an  ob-ject  and  which 
cannot  he  specified  by  iisinp  one  or  more  relat  Lonshi ps  can  be 
specified  in  a narrative  or  text  description  called  a cpminent 
entry.  These  comment  entries  are  not  named  (as  objects  are 
name)  and,  therefore,  apply  to  only  one  particular  name.  A 
number  of  different  tyoes  of  comment  entries  may  be  defined 
doD'=»r.dim  on  the  tvpe  of  object  they  pertain  to.  The  types  of 
narrative  and  free-format  descriptions  that  may  be  defined  in 
accordina  to  the  class  of  objects  being  described  is  given 
in  Pi  on  re  1.4,'^. 


'.4,4  cl  assi  f ica*-  ion  of  Pela  t ionsh  jps  by  System  Aspects 

""h ^ relationships  mav  be  qrouoed  into  nine  major  groups  on  the 
basis  of  *-he  n Qf  the  system  which  they  describe.  These 

nine  maior  aspects  are: 

'^yst'^m  ^Tow 
*^ystom  Structure 
Da  ta  ? *•  rue*-  ure 
Da*-a  Periva*-ion 
System  Size  and  Volume 
Sv-stoni  Dynamics 
System  Architecture 
System  Properties 
Proiec^-  *1anaqomant 

•^ach  is  defin^^d  below.  Snecifying  information  about  each  of 
th“se  aspec*^s  involves  one  or  more  object  types  and 
r“la  ♦•ion  shins.  ’=‘iiure  1.4,6  oresents  a summary  of  these  nine 
aspects  with  corresponding  objects  and  relationships. 


1,4. 4.1  System  e low 

■"ha  '^ys*-pm  '='1ow  aspect  of  the  system  deals  with  the  interaction 
hot-ween  fh“  taroe*-  system  and  its  environment.  This  involves 
describinq  those  obiects  (INPUTS)  which  are  supplied  by  the 
environment  (IN'"  ■=’PFi  CES)  to  the  target  system,  those  objects 
(OU'^p'tTF)  which  arf'  produced  by  ♦’he  target  system  and  accepted 
bv  the  environmen*-,  and  th«  responsibility  of  the  environment 
for  information  (SETS)  within  the  system. 

dnv  transfers  of  da*  a within  the  system  are  not  considered  as 
nar*  of  System  '“Idw  because  there  is  no  interaction  with  the 
er  vi  ronm  en*  . 


'.4.4.2  Syst  om  s true  t lire 

Fvs*om  Structure  Is  concerned  with  the  hierarchies  inherent  in 
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most  t.yp<»5?  of  systems.  (This  inclu'ies  inforuation  structures  as 
wpll  as  processinq  structures.)  Structures  may  also  be 
introdncfi'l  to  facilitate  a particular  design  approach  such  as 
"top  down."  ’"n  this  context  all  information  may  initially  he 
qroiiped  toqother  ari  called  by  one  name  at  the  highest  level, 
and  then  gradually  broken  down.  System  structures  can  represent 
high-level  hierarchies  which  may  not  actually  exist  in  the 
system  as  well  as  those  that  do. 


0*^  OBJECT  TYP’='E 

cokment  entry  pslationship 

opg A NT7.?  TI0>'  OBJECTS 

0'=' SCRIPT  ION 

TAFO’^T  EYS'^EE  CBJEC'S 

DERIVATION 

DESCPIP-^TON 

PROCEDURE 

VOLATILITY 

VDLATILI"’Y-MENBER 

VOLATILITY-SET 

WHILE 

PROJECT  EANA.GEEEVe 
OBJECTS 

DESCRIPTION 

DOopirp^Y  objects 

DESCRIPTION 

Eigura  l.h.5  Types  of  Comment  Entries 
for  each  class  of  Objects 
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SYST’^F  ASPEC"' 

npL  OPJECTS 

URL  RELATIONSHIPS 

SYSTEM  FLOW 

IN'^SPFACE 

INPT^ 

OUTPUT 

PROCESS 

SET 

FSCEIVES/RECSIVED 
GENERATES/GENE  PA.  TED 
UPDATBS/UPDATED 

PE  SPONSIBLE-IN TERR  ACE 

SYSTEM  STRUCTUP*’ 

INTEPFAC'!’ 

TN  PU'^ 
nuTPU'^ 

PROCESS 

SET 

SUBPARTS/PART  OF 

SUBSET /SUBSETS 
UTTLIZES/UTILIZED 

DATA  S'^FUCTUPE 

GPO'IP 

ELEMENT 

FNTJT Y 

CO NSISTS/CCNT AIMED 
IDENTIFIES /IDENTIFIED 
■SUBSETTING- CRITERIA/ 
SUBSBTTING-CPTTEPION 

AS SOCI AT ED/ASS OCIA TED- DATA 

DATA  DFSTVA’^TON 

I NTEFFACE 

TNPU'^ 

OUTPUT 

opOCESS 

SET 

CROUP 

ELEMENT 

ENTITY 

CLA'-SI^'ICATION 

usES/uspn 

DERIVES/DERTVED 

OPOATES/UPDATED 

MAINTA  INS/MAINTAIN  ED 
PROCEDURE  • 

DERIVATION  * 

CLASSIFICATION 

SECUFITY-ACCSSS- 

RIGHTS 

‘SYSTEM  ST7F 

SYSTFM-PAPAMETEP 

IN'^’^RVAL 

CONSISTS 

HAPPENS 

CONNECTIVITY 

CARDINALITY 

VALUES 

VOLATILITY  * 

VOLATILITY-SET  * 
VOLATILITY-MEMBER  • 

SYSTEM  DYNAMICS 

EVENTS 

CONDITION 

CAUSES /CAUSED 
INCEPTION-CAUSES/ 

ON  INCEPTION 

INTERRUPTS /INTERRUPTED 

MA  KES/MADE 

TERMINATES /TER  KINA  TED 
TERMINATION-CAUSES/ 

ON  TERMINATION 

TR IGGERS/TRIGGERED 

WHILE  * 

* 


coitiH><»n  t 


»n  ^ rv 

Fiaure  1.4.6 

u'’ L oh -Jo 3 h anrl  Ftatements  Organized  According 
to  Aspect  of  Target  System  Described 
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SYSTEM  ASPECT 

URL  OBJECTS 

URL  RELATIONSHIPS 

SYSt'EW  APCUITEC^UPF 

PROCESSOR 

PES'^URCE 

PESOUKCE-USAGE- 

PAPAMFTSR 

UNI"’ 

CONSOBES/CONSUHSD 
PEPORHS/PERFORHED 
RESOURCE-USAGE/ 
RESOURCE- USAGE- 
PARAMETEF-VALUE 
MEASUPES/HEASUFED 

PROJECT  WANAGEMENT 

PPOBLEK-  DEFINEP, 
MAILBOX 

RESPONSIBLE/ 

FESPONSIBLE- 

PFOBLEM-DEPINER 

KAILBOX/APPLIES 

PROPERTIES 

ATTPIRUT’=’/ 

ATTRIBUTE- VALUE 
CLASSIFICATION 
KEYWORD 

ME^IO 

SYNONYM 

SOURCE 

SECT!  PITY 
"•RACE-KEY 

ATTRIBUTES /APPLIES 
KEYWORDSAPPLIES 
SEE-BEHO/APPLIES 
SYNONYMS/DE SIGN ATE 
DESCRIPTION  * 
SOUPCE/APPLIES 
SECURITY/APPLIES 
TRACE- KEY/APPLIES 
ASSERT 

* coBiinert  “ntry 


Fiqwr<»  (Continued) 

URL  Ohiect  and  Statement's  Organized  According 
to  Aspect  of  Target  System  Described 
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1.4.  U.^  Da»^ 

Pata  Structures  rpprpsent  tt>p  relationships  that  exist  loonq 
da+’a  used  and/or  minipulatel  by  the  systen  as  seen  by  the 
'•users*'  ot  th®  syster.  Data  Structures  also  exist  in  the  way 
data  is  qroupod  in  rollections  of  information  such  as  dscuments. 
The  description  of  Data  Structures  also  involves  specification 
of  relationships  apong  logical  collections  of  data  and  the  data 
associated  with  such  relationships. 


Oer ivat ion 


’•’he  Pa^'a  Derivation  aspec*-  of  the  system  description  specifies 
the  wav  in  which  data  is  manipulated  or  derived  by  the  system. 

It  specifies  what  information  is  used,  updated  and/or  derived, 
how  •■his  is  dona,  and  bv  which  processes.  This  aspect  differs 
from  sycstetn  Plow,  since  Tystem  Flow  only  designates  the  inputs 
♦■o  th  system  and  th?  end  results  (ODTPHTS)  , without  specifying 
what  actions  ♦■aVe  place  to  bring  these  transf  orma  tions  about. 
Da*-a  Derivation  can  deal  with  the  very  lowest  transformations  of 
da'-a,  whereas,  System  Flow  deals  with  high  level  collections  of 
information  (i.®.,  rvptjTF  and  OUTnijTS)  . 


1.4.4.'i  e^t^ 

I 

"'he  Pystom  ‘^i7e  is  concerned  with  the  si7e  of  the  systea  and  i 

♦■hoso  factors  that  influence  the  volume  of  processing  that  will  j 

be  required.  ""o  describe  system  si7e,  the  parameters  involved 
are  named  as  ob-ject5.  | 


1.4.  4. Syst em  D ynam  ics 

'"he  dynamic  analysis  aspect  of  system  d®scriptiQp  presents  the 
manner  in  which  the  target  system  behaves  over  time.  EVENTS  and 
COWPI-'ION.S  are  used  to  help  describe  when  PROCESSES  are 
p®r^ormed  and  under  what  conditions. 

1.4. 4.7  System  • rch i tecture 

""h®  Svs'-em  A^cbit®c^u^e  aspect  deals  with  the  physical 
'-omnonents  ard  structures  that  are  necessary  in  order  to  realize 
♦^he  qiv®n  user  r eoui  remen ts. 


^.4.4.g  Prod ect  ?5anaiiemert 

■•■n  addition  ^^o  th®  iescription  cf  the  target  system  being 
designed,  iocumontat  ion  of  the  group  designing  (or  documenting) 
th®  •■araet  system  is  needed.  This  involves  i-lentif icati on  of 
p®rsons  involved  and  their  responsibilities,  etc. 


P^PT  T DFEF  PFOUIREflENTS  LANGUAGE  MANUAL 


i 


Mf  1 flO/Mni.TTCS/nFL  nSEP'S»HNnAL  3'4 


l.fi.U.*)  Prr>por» 

Ml  oh1<»ci-s  (of  a nar*’.icular  type)  used  to  describe  the  target 
system  have  characteristics  that  distinguish  than  froa  other 
ohipcts  of  the  sane  ♦’yoe.  Therefore,  the  properties  of 
oarticular  ohiects  in  the  system  must  be  described.  In  general. 
Properties  involve  any  description  particular  to  a given  object. 

I . 3 vst  ew  Pocum  gnt  at  ion  Using  liPL/UP A 

The  Process  of  using  nPL/U?A  to  describe  an  infornation 
orocessj  no  system  includes  the  following  steps; 

1)  gathering  information  about  the  system. 

2)  Pvpressinq  the  information  in  URL. 

■»)  Formatting  URL  as  required  by  URA. 

U)  Converting  •■he  Problem  Statement  into  computer  processable 
form  . 

5)  Entering  ►he  data  into  the  prodect  data-base, 
n)  generating  outpjts  from  the  data-base. 


■*.E.  1 Ua  ► h'^r  i ng  Information  About  the  System 

"’his  step  can  be  carried  out  as  with  present  manual  methods. 
Powever,  the  MPL  structure  (sections  and  statements)  can  be  used 
as  a structure  for  which  information  is  collected.  UPA  outputs 
can  also  bo  used  as  a checklist  of  missing  information. 

^.^.2  Expressing  the  Information  in  URL 
"'he  uso  of  UPL  consists  of: 

- Identifying  obiec^s,  naming  them  and  assigning  a unique  type 
to  each. 

- pofqrmining  *-h  » relationships  among  the  objects, 

- 3*-a^irg  appropriate  nroperties  for  each  object. 

Anv  information  which  cannot,  be  expressed  in  this  formal  syntax 
can  be  given  as  text  in  comment  entries. 


i.'j.l  formatting  UPL  as  Peguired  UPA 

n^A  requires  only  minimal  focmattinq  as  described  in  Section 
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w Conv^r  ting  Pl2l2lSS  S ta  tement  into  Coapu  ter  ?C3 cessabla 

form 

""h*^  ntoMem  stat-^ment  can  be  read  by  OPA  from  whatever  form  of 
comnuter  nrocessabla  input  is  desired.  The  usual  procedure  will 
be  to  punch  the  orohlem  on  cards  or  to  enter  it  via  a terminal. 

data  can  bo  entered  on  cards  anywhere  in  th*  first  72 
columns. 

when  data  is  enterei  via  a terminal,  it  will  normally  firs*-  he 
entered  into  a file. 


?n  t rv  of  the  p a ta  into  the  Pro  iect  Data  B|se 

In  ’■^DOP.  terminology,  the  description  of  a oroposed  Information 
Processina  'System  is  called  a Problem  Statement  in  the  sense 
that  it  represents  a "problem"  to  be  solved.  The  physical 
system  designer  t>,an  has  the  problem  of  finding  the  best  system 
to  accomplish  the  requirements  implicit  in  the  description  of 
the  ororos^d  Informal- ion  Processing  System.  (The  proposed 
system  can  be  considered  a solution  to  an  earlier  oroblam, 
namely,  th^  rrohlom  of  what  outputs  are  necessary  to  satisfy  tha 
"users"  needs  for  information.)  The  IJPA  data-base  contains  the 
problem  statement  as  it  has  been  given  up  to  that  time. 

'^he  rrohlem  s*:atempnt  will  he  built  up  over  a period  of  time, 
possibly  by  a number  of  problem  definers  working  simultaneously. 
'^hr‘>e  aspects  of  a problem  statement  and  itg  use  during  logical 
system  design  need  o be  considered: 

1)  '’’he  documentation  of  the  problem  statement  avail?' te  to  tha 

rrohlem  def  iner  based  on  the  HRL  information  in  the 
lat  a-hase. 

?)  The  problem  sta«:emont  as  it  exists  in  the  data-base. 

the  data-base  contains  information  about  all  the  obiects  that 
have  boon  identitiei,  and  all  the  relationships  among  those 
ob-joc’-s  that  have  been  specified.  It  also  contains  narrative 
statements  to  be  use^t  in  the  final  documenta t ion , Except  for 
the  narrative  statements,  the  data  is  stored  in  "coded"  form  and 
not  as  a copy  of  -ho  FOP'iATTED  PPOBLIK  STATEMENT, 

’)  The  method  by  which  tha  problem  statement  is  added  to  or 
modi  fied . 

when  the  problem  definer  wishes  to  add  to  the  data-base  or 
modify  it  in  some  way,  input  is  prepared  according  to  the  syntax 
ot  n^x,  i.e. , in  the  same  form  as  the  FORMATTED  PPOBLEN 
STA”  FMEN  t . However,  only  new  data  or  changes  to  the  data  need 
♦•o  be  entered.  Any  data  not  affected  by  the  input  will  remain 
unchanged. 
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■"h'*  us®  of  MFL,  fh!?r®f OTP , diffprs  from  prpspnt  methods  in  two 
sianifican*"  ways;  thp  information  about  a proposed  systam  can  ba 
on’-^rpd  in  any  order  and  only  new  data  or  chanqes  need  be 
»n  tPTf d . 


1 . F , f qpnera  t im  Out  puts  from  the  Da  ta  Base 

At  any  time  problpp  definers  ran  obtain  outputs  based  on  all  or 
nart  of  thp  data  in  the  data-basp.  These  outputs  would  be  used 
by  the  problem  definers  in  their  own  work  (Data  Collection, 
Analysis,  Design,  Fvaluation  or  Improvement)  or  in  conferring 
wi*-h  users  and  others.  The  complete  statement  containing  all 
the  data  in  t h®  data-base  is  called  the  FORMATTED  PROBLEM 
F"'A’^ T . "^hp  other  outputs  contain  subsets  of  the  total 
documentation,  summaries,  rearrangements  and  analyses.  The  URA 
User’s  Manual  gives  a complete  description  of  each  report 
available  t^  t.he  problem  definer. 

The  FOF'l  SITED  PDOPt.Er  STATEMENT  is  based  on  all  the  data  in  the 
da’-a-bas®.  It  is  not  merely  a listing  of  the  data  that  has  been 
entered  bu*-  includes,  in  addition  to  the  relationships 
®xnlicitly  stated,  those  that  have  been  implied  (i.e., 
complementary  ro  lat  i onshi  os)  . The  FOPMATTED  PROBLEM  STATEMENT 
is  "syntactically"  correct,  i,e.,  it  can  be  processed  by  ORA. 

In  nrac*ice  problem  definers  would  use  the  FORMATTED  PROBLEM 
STA"  in  con  "junct  ion  with  ether  reports  from  ORA, 


■» . o peer  2£2JJiE2i!l£Ili§  Langua ge j Syntax  S tructure 

Since  PPL  is  a language  which  must  he  understood  by  a computer 
program,  (PR  A),  it  must  have  a formal  s’-ructure,  usually 
referred  to  as  syntax.  In  this  section,  the  syntax  structure  of 
PPI  is  outlined.  s more  detailed  statement  of  the  syntax  for 
P?L  appears  in  " Pser  Reguiraments  language.  Language  Reference 
Manu  al . " ‘ 


1.6.'’  Langua qe  Structure 

P^L  consists  of  several  levals; 


HHL  b^scription  Constitutenta 


Target  System  Description 
PPL  Sect  ion 
PPL  Statemants 

ooserved  Words,  Names,  Numbers 
Cha  racters 


A description  at  each  level  consists  of  one  or  more  units  of  ths 


’ "art  IT  of  this  document. 
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siiccp€<iina  lev<»ls.  A systpm  inscription  consists  of  ons  or  mors 
fJPL  sections.  \ nPL  section  consists  of  one  or  more  OPL 
statements,  Each  UP  I,  statement  is  formed  by  some  combination  of 
Peserved  words,  Nam=»s,  and/or  numbers.  Finally,  the  Peserved 
Words,  Names  and  Nu'nbers  consist  of  characters  allowed  by  the 
UPL  character  set. 

The  syntax  of  the  constituents  at  each  level  are  defined  in  the 
remainder  of  this  section. 

1.6.2  Pr ohlew  St atewent  Format 

UPL  is  a free-forma*^  lanquaqe  in  contrast  to  ”€  i xed- f ora  at " or 
tilar  . In  par*:icular,  this  means  that  URL  descriptions  can 
appear  anywhere  on  the  physical  medium,  such  as  punched  cards 
and  that  within  fairly  wide  limits,  information  can  be  entered 
in  a nv  o rder . 

■"he  pronram  which  "reads'*  the  Problem  Description  understands  or 
decodes  the  descrinticns  by  reorganising  a delimiter  the 
semi-colon  {:)  and  Peserved  Words.  The  latter  are  defined  in 

1.6.6. 

’’’he  major  advan*'age??  of  fre^  format  are  that  complex  problem 
s*-atemerts  can  he  made  with  relative  ease  and  the  problem 
s*-a*'emerts  can  b“  made  fairly  concise. 

Forms  can  be  lesigrod  if  a more  structured  method  of  recording 
thr»  nioMem  sta*-emen*-  is  required.  One  possible  organization  of 
♦•he  forms  is  given  in  Section  3. 

1.6.  Target  '^ys  tern  I den  tif  ica  t ion 

Only  one  u®A  data-base  is  needed  to  store  all  information  about 
a given  .System.  ”'6  i s data-base  represents  the  up-to-date 
version  of  th®  system  description.  UFA  has  facilities  for 
specifying  the  name  of  the  system  being  described  on  all  reports 
generateri  from  the  data-base. 


1.6. U UFL  Fections 

A *rFL  description  or  Problem  Statement  consists  of  one  or  mote 
UOL  sections.  Fach  sec*-ion  consists  of  one  or  more  URL 
q^atomonts.  The  first  statement  in  a section  (and  the  only 
required  one)  is  called  •■he  Section  Header,  A Section  Header  is 
a UP  1 statement  that  identifies  a section  and  specifies; 

1)  That  ♦•he  user  defined  names  given  in  the  section  header  are 
a particular  object  type  (e.g.,  PFOCESS  or  SET,  etc,), 

7)  That  any  URL  statements  (up  to  the  next  Section  Header) 
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prf'sent  some  'description  about  the  name  (s)  qiven  in  the 
header  and/or  form  relationships  between  names  in  the 
header  and  other  user-defined  names  in  the  problem 
sta  teiii»»nt. 

""here  are  a finite  number  of  URL  statements  that  are  defined  as 
Section  Headers  and  are  qiven  in  "'able  5. 

co»:  Di'^iov 
rFFINS 
CFSISVA"*: 

PIEMEN" 

ENTITY 
EVEN" 

HROnp 
INPUT 
INTE’”='ACE 
INT*'PVAL 

Table  5.  Section  Header  Statements 

Nos*-  obiect  types  are  defined  in  sections  of  the  same  time, 
i.=».,  a PROCESS  would  be  defined  in  the  PROCESS  section. 
Therefore,  there  is  a one  to  one  correspondence  between  types  of 
ohiec+s  and  section  headers  except  that  the  followinq  types  of 
obipcts  are  all  defined  in  a DEFINE  section: 

jl'T’ToirjrrTE  SFCfJPITy 

AT""’=I3nTE-V  ALHF  SOUFC’" 

CLASSTPICATint:  St'BSFT'T’TNG-CF  ITER  ION 

KEYWORD  SYSTEH-PASAMFTEP 

MAILBOY  "RACE-KEY 

an  1 a Svnonym  is  assiqned  to  an  object  by  a DESIGNATE  section. 
This  distinction  be*- ween  Type  of  Object  and  Section  Header  is 
imma*-prial  conceptually  su'd  is  introduced  only  to  simplify 
enterinq  URL  informa*- ion  into  the  data-base  since  all  the  Types 
of  Objects  described  in  a DEFINE  section  allow  essentially  the 
same  set  of  statements. 

For  each  type  of  section  header  there  are  a finite  number  of 
ditferor*-  UPL  s^-atements  tha*  can  be  specified  after  it.  For 
examole,  if  ♦-he  section  defines  a name  to  be  an  INPUT  it  may  be 
desirable  ♦•o  sav  what  GEtEPATES  and  what  RECEIVES  the  INPUT,  but 
it  would  he  illoqical  to  say  that  the  INPUT  MAINTAINS  other 
information.  '"het'^fore,  there  are  a select  set  of  URL 
s*-atemonts  tha*  may  be  used  in  conjunction  with  a particular 
Seedier  Header.  "ho  Section  Summaries  in  Section  .1  and  in  "User 
Fean  i remen  rs  Lanquaqe,  Lanqiiaqe  Reference  Manual,"*  present  a 
lis*-  cf  which  HP  L statements  which  can  appear  in  each  type  of 
sect  ion . 

* Pa  r*-  TI  of  this  document. 


M E"0 
OUTPUT 

PPOHIEM- DEFINFP 
PROCESS 
rPOCESSOR 
PELATTON 
P EEOUPCE 

RESOURCE -US AGE-PARAMETER 

SET 

UNIT 
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a ^ew '3n<~ s 

Thorp  aro  throp  basic  ♦■ypos  of  nPL  sf afements: 

1)  Section  Ueaiier  statement  - This  type  of  statement  is  used 
to  define  one  or  more  names  (objects)  to  he  a particular 
object  type  (e.q.,  PPOTESS  or  GPOUP)  as  described  above. 

2)  pplationship  statement  - This  type  of  statement  is  used  to 
specify  relationships  between  or  amonq  objects.  In 
snocifyinq  th?  tarqe^-  system  description,  it  is  necessary 
to  describe  which  TNTEPi'ACES  supply  which  INPUTS  to  which 
PROCESSES,  what  data  (GROUPS  and  ELEMENTS)  are  used  by  what 
PPOCFESES,  what  EVENT*?  cause  which  PROCESSES  to  be 
triqqered,  and  how  often,  etc.  For  each  type  of  object 
particular  relationships  can  be  specified  as  outlined  in 
1.U  and  doscribed  in  more  detail  in  Section  2 and  3.  For 
example,  a relationship  between  an  OUTPUT  and  the  PROCESS 
which  producer  the  OUTPUT  would  be  specified  by  the 
CENEPA^FS  statement.  A PPCCFSS  can  GENEPATF  an  OUTPUT, 
likewise,  an  OUTPU""  may  be  G’fNERATED  by  a PROCESS. 

?)  Ccirni''r.t  ^n^ry  s ta’-emen*-  - ^his  type  of  statement  is  used  to 
relate  a narrative  for  text)  description  (comment  entry)  to 
a par*-icular  oh  iect . Text  descriptions,  therefore,  may  be 
used  to  aunoloment  relationships;  this  means  that  any 
in  *"orma  t ion  which  cannot  be  directly  specified  in  one  or 
more  relationships  (relationship  statements)  can  be 
presented  in  a narrative  format. 

®n  URL  statementci  heqin  with  a reserved  word  and  are  terminated 
hy  a semi-colon  (;).  If  the  statement  specifies  a relationship 
(one  cf  th“  tynes  statements  defined  previously)  then  the 
statement  must  also  consist  of  one  or  more  user  defined  names 
and  may  not  r^au  ire  one  or  more  reserved  words.  Optional  words 
may  he  inserted  in  the  statements.  For  example; 

R’^CEIVKD  PY  employee-orocessinq ; 

hoqins  with  the  res'^rved  words,  RECEIVED,  which  is  followed  by 
an  optional  worl , BY,  then  by  a user-defined  name, 
'•amployoe-proressinq '•  and  finally,  terminated  by  a semi-colon. 
Ulanks  are  used  to  separate  words  and  names  in  the  statement. 

Any  number  of  blanks  may  be  used  where  one  blank  is  allowed. 

If  the  statement  is  a comment  entry  type  statement,  then  the 
first  line  of  the  statement  may  only  consist  of  reserved  words 
and  the  semi-colon.  Succeed inq  lines  of  the  statement  are 
interpreted  as  t h®  comment  entry  text  until  a semi-colon  is 
encountered.  "■h«refore,  a semi-colon  may  not  be  used  in  the 
text  of  a comment  entry  statement.  For  example; 

DESCPIP'’’TON  ; 

The  time  card  is  the  record  of  hours  an  hourly 
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i»mplovee  worlcf*^  in  any  given  week.  ; 

^nv  characters,  except  the  seni-colon,  nay  appear  in  the  text  of 
a cawment  entry  such  as  the  period  (.)  in  this  exaaple.  The 
comeent  entry  text  may  not  begin  on  the  sane  line  as  the 
reserved  wprd  for  the  statenents. 

In  many  statenents  which  specify  relationships  anong  objects,  a 
list  user  defined  names  nay  be  given.  ^ov  exanple: 

ns*"*?:  *'ica-tax,  federal-tax,  state-tax; 

desiona*-es  that  the  names  in  the  section  header,  to  which  this 
statement  belongs,  USE  fica-tax,  federal-tax  and  state-tax. 
Planks  may  be  used  on  either  side  cf  the  commas  separating  the 
user  defined  names. 

•bbreviations  of  reserved  words  nay  be  used  in  place  of  the  full 
reserved  word,  Eor  exanple: 

FEC^IVED  BY:  employee-processing; 

may  also  be  given  as: 

PCVD  employee-processing; 

allowable  abbreviations  (which  are  also  designated  as  being 
reserved  words)  are  given  in  Appendix  D of  "The  User's 
Pogn  iremen«-s  Language,  Language  Reference  Manual, '•» 

1.6.^  Pesepyed  Words,  Mames  and  Numbers 

Reserved  words  are  c omb ina'-i ons  of  letters  and  dashes  used  to 
identify  UPL  section  headers,  URL  statements  an!  optional  words, 
’"here  is  a limited  number  of  reserved  words  as  given  by  Appendix 
B of  """he  User's  Peg u irement  s Language,  Language  Reference 
Tanual."»  Ml  reserved  words  are  defined  by  the  flRL/URA  system 
and  nav  rot  be  changed  bv  the  user. 

'Untional  words  mav  be  used  by  the  problem  definer  to  improve  ths 
readability  of  the  problem  statement.  (fords  like  BY,  A,  ARE, 
AVn,  etc.  are  legal  UPL  optional  words.  Appendix  C of  "The 
User  Peouirements  Language,  Language  Reference  Manual"  is  a list 
of  all  npL  optional  words.  In  the  following  UPL  statement: 

U‘?PD  "Y  emnloyee-processing  TO  DERIVE  paycheck; 

♦•h®  words,  USED,  PY,  TO  and  DERIVE  are  URL  reserved  words. 

User  defined  names  are  any  names  (words)  used  in  a URL  statement 
♦•ha'-  are  not  U^L  reserved  words.  Restrictions  on  user  defined 

‘ ♦'art  IT  of  this  document. 
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name's  ar«>  that  they  may  only  benin  with  a letter,  consist  of 
only  letters,  dibits  an<1  dashes,  and  be  no  lonqer  than  thirty 
characters  in  lenath,  "he  names  "employee- processing"  and 
"pavcherk"  in  the  previous  axample  are  instances  of  user  defined 

namos. 

Numbers  us'^d  in  a T??  I.  statement  may  only  consist  of  the  digits  3 
throuoh  Q with  no  decimal  points  plus  or  minus  signs,  etc., 
allowed. 


1 . n . Character  set 

All  Reserved  words,  names  and  numbers  must  be  composed  of 
characters  in  the  rPl  character  set.  The  attached  list  gives 
for  each  ASCII  character  a code  of  1 to  4 classifying  the 
characters  into  *-he  following  categories; 

Code  1:  Nonprinting  operating  System  and  transmission  control 
characters  to  be  treated  as  punctuation,  hut  will  always  be 
illegal. 

Code  2;  Puncutation,  delimiters,  etc.  which  are  not  allowed  in 
names , 

Cole  a;  Characters  allowed  any  position  in  a name. 

Code  4;  Characters  allowed  at  any  position  in  a name  after  the 
first . 

■^here  are  three  versions  of  this  categorization: 

1.  A one  page  summary. 

?.  Sorted  by  Octal  representation. 

d.  Sorted  bv  code,  then  by  Octal  representation. 
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I CO’)’?  1;  All  ot.hers 

CO')^  2:  *,;;=?[  11^ 

CO!)F  B BCDEFOHI  JKI  rNOPORSTDVWXYZ 

ibcrtf»fghi  Iklmnopqrstuvwxyz 

I # 1!<(  )\  ‘ 

CO*)!:  4;  0 12'’4  5F74  9 

jj 

I 


I 

I 
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cons 

nr,  TAL 

CHAP 

NAME 

"ooo“ 

ru  1 

null  or  time  fill  char 

1 

001 

soh 

start  of  heading 

1 

002 

si-x 

start  of  text 

1 

0 0 0 

at  X 

end  of  text  (E0?1) 

1 

0 04 

eot 

end  of  transmission  (EOT) 

1 

0 05 

pfiq 

pnquiry  (WPU) 

1 

Of 

ack 

acknowledge  (RW) 

1 

07 

bpl 

bell 

1 

01  r 

bs 

backspace 

1 

011' 

ht 

horirontal  tabulation  (TAB) 

1 

^ 12 

If 

line  feed  (LINE  FEED) 

1 

013 

vt 

vertical  tabulation  (VT) 

1 

7 14 

ff 

form  feed  (FORM) 

1 

0 1*^ 

cr 

carriage  return  (PSTORN) 

1 

7 If 

so 

shift  out 

1 

0 17 

si 

shift  in 

1 

0 27 

11  e 

data  link  escape 

1 

721 

del 

device  control  1 (X-ON) 

1 

72? 

dc? 

device  control  2 (PAPS) 

1 

0 27 

1c3 

device  control  3 (X-OFF) 

1 

0 24 

dc4 

device  control  4 (TAPE) 

1 

0 TC 

na  k 

negative  acknowledge 

1 

7 2f 

syn 

synchronous  idle 

1 

0 27 

p b 

end  of  transmission  blocks 

1 

0 30 

can 

cancel 

1 

.0  31 

err 

end  of  medium 

1 

0 32 

ss 

special  sequence 

1 

7 33 

p sc 

escape 

1 

7 34 

^ s 

file  separator 

1 

7 35 

qS 

group  separator 

1 

7 3f 

rs 

record  separator 

1 

0 37 

us 

unit  separator 
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CODE 

nc'^AT. 

CHAF 

NAME 

0 4'' 

so 

soace  (SPACE  BAP) 

1 

0 41 

1 

exclamation  point 

? 

'*42 

II 

quotation  marli 

1 

343 

« 

nuabec  siqn 

3 

0 44 

It 

currency  syabol 

3 

n 4c 

t 

percent 

2 

n 4<; 

& 

ampersand 

2 

A 47 

• 

apostrophe 

3 

3 'i'' 

( 

openinq  parenthesis 

OSI 

) 

closinq  parenthesis 

2 

3 52 

* 

aster isk 

!J 

35> 

♦ 

plus 

2 

A 54 

t 

comma 

u 

55 

- 

hyphen  or  minus 

u 

3 5^^ 

. 

period 

u 

A 57 

/ 

slant 

4 

3 60 

0 

zero 

U 

351 

1 

one 

U 

•A  62 

2 

two 

4 

A ^3 

3 

three 

U 

A 64 

4 

four 

4 

36*= 

5 

five 

4 

3 '•-6 

6 

si  X 

4 

0 

7 

seven 

4 

A TA 

5 

eiqht 

4 

A 71 

Q 

nine 

2 

0‘'2 

; 

colon 

2 

A73 

• 

semicolon 

4 

A74 

< 

less  than 

2 

A75 

•= 

equal 

4 

'76 

> 

qreater  than 

2 

377 

7 

question  mark 
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ocrAL 

NAME 

”3“ 

’ioo” 

i 

commercial  at 

3 

101 

A 

3 

1 32 

D 

3 

133 

C 

3 

104 

n 

■» 

105 

p 

3 

1 Ofi 

F 

3 

lO"' 

G 

1 

H 

3 

1 11 

I 

•j 

1 12 

J 

3 

1 1 3 

K 

■) 

1 14 

L 

3 

115 

K 

3 

1 16 

N 

3 

1 17 

0 

3 

1 2^ 

P 

3 

1 21 

0 

3 

1 22 

R 

3 

1 2^ 

s 

3 

1 24 

T* 

3 

1 25 

n 

3 

1 26 

V 

3 

1 27 

u 

3 

1 ?f' 

Y 

3 

1 31 

Y 

3 

1 32 

7 

1 

1 33 

[ 

openirg  htacket. 

T 

1 34 

reverse  slant 

2 

1 7r 

1 

closing  bracket 

3 

1 36 

A 

circu  mf  lex 

4 

1 37 

underline 
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roP2 

r 

3 

•? 

■? 

3 

3 

3 

3 

3 

3 

3 

3 

3 

3 

3 

3 

3 

3 

3 


1 


OCTAL 
“■?  40” 
1 41 
1 42 
143 
1 44 
14S 
1 Uf^ 

1 4'» 

1 '■jO 

1 51 
152 
1 53 
1 '^4 
1 <^5 
1 56 
1 57 
1 6P 
161 
162 
1 63 
1 64 
16'^ 

1 

■I  67 
1 70 
171 
1 72 
1 "h 
1 74 
1 

1 76 
1 •’7 


£HAP 

x”” 

a 

b 

c 

<1 

(» 

f 

Q 

h 

i 

1 

k 

1 

m 

n 

0 

D 

a 

r 

s 

u 

V 
u 
X 

V 

7 

f 

1 
} 

/>> 

del 


NAME 

qrave  accent 


opening  brace 
vertical  line 
closino  brace 
tilde 

delete  (PUBOtr) 


t’ap: 
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cort'' 

CHAP 

liiSI 

r 

~co” 

nu  1 

null  or  time  fill  char 

1 

OOl 

soh 

start  of  heaflinq 

1 

''02 

st  X 

start  of  text 

1 

■'''3 

et  X 

end  of  text  (EOM) 

1 

0 ')4 

«»o  t 

end  of  transmission  (EOT) 

1 

0 '5 

era 

enquiry  (WPO) 

1 

706 

ack 

acknowledqe  (RU) 

1 

nr(7 

bol 

bell 

i 

Tift 

hs 

backspace 

1 

ft1i 

ht 

horizontal  tabulation  (TAB> 

1 

”7  12 

If 

line  feed  (LINE  FEED) 

1 

“in 

vt 

vertical  tabulation  (VT) 

1 

0 14 

ff 

form  feed  (FORM) 

1 

0 16 

cr 

carriage  return  (RETURN) 

1 

0 16 

so 

shift  out 

1 

0 17 

si 

shift  in 

1 

0 20 

4 Ip 

iata  link  escape 

1 

^21 

4c1 

device  control  1 (X-ON) 

1 

ft  22 

dc2 

device  control  2 (TAPE) 

1 

'2'’ 

1c3 

device  control  3 (X-OF’') 

1 

0 24 

4 cU 

device  control  4 (TAPS) 

1 

n 2C 

nak 

negative  acknowledge 

1 

26 

sy  n 

synchronous  idle 

1 

0 27 

ef  h 

end  of  transmission  blocks 

1 

0 

can 

cancel 

1 

0 31 

em 

end  of  medium 

1 

0 32 

ss 

special  seguence 

1 

0 33 

esc 

escape 

1 

0 34 

fs 

file  separator 

1 

0 36 

qs 

group  separator 

1 

0 36 

rs 

record  separator 

1 

ft  3ft 

us 

unit  separator 

1 

1 77 

4p1 

delete  (RnBOOT) 
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OC^AT. 

CH^ 

uai 

“O  4C“ 

sp 

ipace  (SPACE  BAB) 

042 

It 

quotation  aark 

0 46 

R 

aapersand 

0 47 

1 

apostrophe 

0 ■52 

* 

asterisk 

0S4 

9 

coama 

072 

• 

• 

colon 

7 73 

t 

seaicolon 

0 76 

- 

equal 

0-'7 

■> 

question  mark 

1 33 

f 

opening  bracket 

1 36 

1 

closinq  bracket 

173 

t 

openinq  brace 

1 74 

1 

vertical  line 

1 75 

\ 

closinq  brace 

1 76 

tilde 
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CODS  nC^AL  CHAP 

3 "oli'l"  T 

3 ^43  * 

3 ttU  t 

3 0 a r 

; 0 ( 

3 0 31  ) 

3 10''  i 

1 1 'll  ^ 

3 1 '>2  R 

3 103  C 

’ 104  D 

3 inn  p 

3 1 ''P  P 

3 107  3 

3 in  H 

1 111  r 

3 112  .1 

3 113  K 

3 114  T. 

•J  1 in  ^ 

3 m N 

3 117  n 

3 1 2^^  P 

» 121  o 

3 1 22  R 

Tt  120  <? 

3 124  ? 

3 1 2’^  n 

3 ^2f  V 

3 1 27  H 

3 13''  y 

3 131  Y 

3 1 32  7. 


M A«^ 

exclamation  point 
number  sign 
currency  symbol 
percent 

opening  parenthesis 
closing  parenthesis 
commercial  at 
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OCTAL 

CHAP 

y” 

”i  3U” 

3 

1 3f 

A 

3 

1 UC 

\ 

•j 

141 

a 

3 

1 42 

h 

143 

c 

3 

1 44 

d 

3 

14*; 

a 

■3 

1 4f 

f 

3 

1 47 

q 

3 

1 50 

h 

3 

1 51 

i 

3 

1 52 

i 

1 

1 53 

k 

3 

1 54 

1 

3 

155 

m 

3 

1 5f 

n 

3 

1 57 

o 

3 

1 6C 

p 

3 

1 51 

q 

3 

1 52 

r 

3 

153 

s 

■> 

1 54 

•j 

1 55 

u 

3 

1 55 

V 

3 

1 57 

w 

3 

1 1'' 

X 

3 

171 

Y 

1 

1 ~>2 

z 

NAME 

reverse  slan«- 
circuHf lex 
grave  accent 
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C02E 

OC'^AL 

CHAP 

NAME 

~u~ 

“'I53' 

nlus 

li 

55 

- 

hyphen  or  minus 

4 

0S6 

• 

period 

4 

057 

/ 

slant 

4 

0 60 

V. 

zero 

4 

61 

1 

one 

4 

2 

two 

U 

0 6’ 

1 

three 

4 

064 

4 

four 

'4 

065 

5 

five 

i 

0 6f 

6 

six 

4 

0 67 

7 

seven 

4 

n 70 

P 

eiqht 

4 

P71 

q 

nine 

4 

C74 

< 

less  than 

4 

f 76 

> 

qreater  than 

4 

1 17 

- 

underline 

ono  excop^ion  *:o  this  is  <-hat  any  characters  nay  be  used  in 
♦•ho  t^xt  of  a comn'er.t  entry  statement. 

1.6.®  Format  Pes  trie  t jons 

While  rjF  L is  a free  format  lanquaqe,  there  are  certain 
restrictions  that  have  been  incorporated  into  the  impleientation 
of  MPA  to  facilitate  entry  of  Problem  Statements. 

One  restriction  is  concerned  with  length  of  the  statement. 

■^houTh  a statem-‘nt  may  extend  over  any  number  of  lines,  only  the 
first  02  columns  of  a card,  or  characters  in  a nessaqe  of  each 
lin'’  may  be  used.  Anythina  over  this  will  be  iqnored. 

""herofore,  the  statement: 

®?CFIVEn  PY;  employee-pr  ocessinq  ; 

may  also  be  aiven  as: 

or  rp 

p V 

e mployee- orocessi nq 


with  nc  effect  on  how  this  statement  is  interpreted  by  U RA . The 
onlv  restriction  is  that  the  statement  may  only  be  split  where  a 
blank  is  allowed  an'i  not  in  the  middle  of  a reserved  word  or 
user  defined  nam**. 

A second  restriction  is  the  one  mentioned  above  for  comment 
entries,  ""he  type  of  Comment  Entry  such  as  DESCRIPTION  or 
poocfDnPE  must  aooear  on  a separate  line,  followed  by  the  text 
endinq  in  a semi-colon. 
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A thiu'l  rpr;<- rict  ion  is  thp  us^  of  EOF  as  a special  type  of 
s^atpaert  ♦•hat  iesit^pates  the  end  of  a collection  of  ORL 
sec*- ions  to  be  used  as  input  to  UFA.  '’'his  statement  spacifies 
that  there  are  no  more  PFL  statements  followinq  and  that  URA  nay 
stop  processing  of  the  ”FL  statements.  The  EOF  statements  must 
be  used  whenever  URL  statements  are  qiven  as  input  to  the 
INPUT-PEL  or  D’=‘LETF-P5L  commands  in  UFA. 


1.T  ccnparison  of  Fan tia  1 and  Computer-Aided  Docqment at ij.? n in 
Logical  Systems  Pes jqn 


1 Description  in  a Structured  Lanqua ge  Comp^ red  to  Hanua^. 
Method s Us ing  Narrative,  Forms  and  Charts 


A number  of  dasirable  properties  of  documentation  were  outlined 
in  Section  t.'’.  The  presen*-  manual  and  computer-aided  methods 
may  b compared,  as  follows; 


Presen  t 
**aniial 
Do  rumen tat  ion 

Hard  ♦’o  Unders*-ap.d 
Am  biguous 
In  ronsis*-ent 
In  complete 
In  corr  ect 

Difficult  *-0  Analyze 
and  Evaluate 
dard  to  Modify 


Compu  ter-Aided 
Docum  entat ion 

Up  der  stands  hie 
Precise 
Cor.si  stent 
Comnl  e te 
Correct 

Computer-Aided  Analysis 
and  Evaluation 
Com pu  te r- Aided- Up dating 


A more  comprehensive  description  of  how  desirable 
characteristics  of  computer-aided  documentation  can  be  achieved 
is  given  in  Section  s.  '"he  contribution  of  the  structured 
description  languai?  is  outlined  in  1.7.2  and  the  contribution 
of  the  outputs  available  for  UFA  is  outlined  in  1.7.3. 


^.T.2  The  Advantage  of  a Structured  Descript ^on  Lang uaq^ 

“"he  maior  characteristics  of  UPL  for  describing  systems  are: 
1)  Each  obi ect  has  a unique  name. 

">)  ^ach  relationship  has  a precise  format,  i.e.  , syntax. 

3)  Only  a specified  number  of  relationships  may  exist  among 
obiects  of  given  types. 

U)  Any  number  of  properties  may  be  defined  for  obiects  of  a 
given  tvp<»  hut  each  property  must  he  uniquely  name'). 

""he  differences  between  UPL  and  the  usual  method  of 
documentation  with  narrative  text  and  manual  flow  charts  are 
shown  in  th“  following  table: 
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Narr ativ  e 

U^ 

nblect  Names 

unlimited 

unique 

Number  of  obiects 

unlimited 

essentially  unlimited  - 
limited  only  because  naa^ 
must  not  be  more  than  30 
characters  and  the  first 
letter  character  must  be 
a letter 

*"700  of  obiects 

not  necess- 
arilv  stated 

relatively  small  number 
of  explicitly  defined 
types 

Peia  ion  ships 

unlimited  and 
not  necess- 
arily expli- 
citly defined 

relatively  small  number 
of  explicity  defined 
types 

Propcrti es 

unlimited  and 
not  necess- 
arily expli- 
citly defined 

unlimited  hut 
explicitly  defined 

1.7.3  Out^gjts  ivailjMe  from  MR  A 

TIP  ^ nrovidi?.*:  i n'>mh=r  of  standac'l  outputs  which  can  be  usei  to 
satisfy  ♦•he  florii  ment  a ti  on  requirements  for  aiding  the: 

ProMem  Definer  in  His  Own  Work 
orohlem  Definer  in.  Communication  with  risers 
Coordination  in  Proi^ct 
rinal  Documentation 

l.'T.U  rh anqes  in  Logical  Dosian 

■^he  use  of  a com  nut  = r-a  ided  system  allows  changes  in  the  way 
looical  design  is  carried  out.  Table  1.7.1  summarizes  the 
differences  between  the  manual  and  computer-aided  methods  and 
the  resul*-ing  improvements  in  the  various  logical  systea  design 
ac*-i  vi»-er?;  data  collect-ion,  analysis,  design,  evaluation  and 
i r>  nr  ov*-  m eTit . 


I 

i 

i 
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Difference  Between  Hanaal  and  Coapu  ter- Aided 
•ie<-  hods 


Pata  '•oras  of  standard  URL  foraat  can  he  used  to 

roliection  record  collected  data. 


Analysis  Analyses  for  correctness,  conpleteness  and 

consistency  of  data  are  done  when  inputting 
data  to  ORA  and  on  demand  from  ORA. 


Design  of  Though  design  is  a creative  process,  ORA  can 

Proposed  Sv=;te"<  make  more  data  available  to  the  designsr  and  in 

a formatted  matter. 


?valiia«-ion  UEA  generates  accurate,  standard  reports  to  aid 

in  the  evaluation  process. 


Tmorovein ent  Modification  of  the  problem  statement  is  easily 

made  through  availability  of  data-base 
modification  commands. 


Imorovenient  in  Computer-Aided  Methods 


Data  Outputs  from  0»*A  can  provide  a checklist  for 

Collection  deciding  what  additional  information  is  needed. 


Analysis  Use  of  the  "ORA  data-base"  insures  that 

analysis  is  always  performed  on  an  up-to-date 
version  of  the  problem  statement.  As  new 
analysis  methods  are  developed,  they  can  be 
incorporated  into  ORA. 


Design  of 
Proposed  System 

Os?  of  the  UFA  reports  allows  the  designer  to 
loot  at  particular  aspects  of  the  system  of 
interest.  Simple  modifications  to  the 
daf-a-base  ran  present  alternatives  in  design. 

Eval uati on 

ORA  provides  some  rudimentary  facilities  for 
computing  volume  or  work  measures  from  the  data 
in  the  problem  statement.  As  additional 
methods  are  developed,  they  can  be 
incorporated . 

Tmorovement 

Rather  than  "starting  from  scratch"  to 
incorporate  changes  in  the  prohlem  statement, 
improvements  can  te  made  on  the  original  ORA 
dat  a-ba  se . 

▼able  1.7.1 

Changes  in  Logical  Design  Procedure  and  Value  of  Change 
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rFOBLKI  S'".*?  rlKR”?  FACIIITT5'=  PY  SYSTFK  ASPECT 

To  accurately  doscrihe  a systam  it  is  necessary  to  describe  all 
asDocts  identified  in  1.4,  The  following  sections  present  the 
'’PL  ohiects  and  ”PL  statements  that  pertain  to  each  aspect  of 
the  system  description; 

System  Flow 
System  Structure 
Data  structure 
Data  Derivation 
System  Sizo 
System  Dynamics 
System  Architecture 
System  Properties 
Proiect  'lanagement 

Guidelines  are  also  provided  to  aid  the  analyst  in  describing  a 
particular  system  in  ijsl,  includinq  guidelines  to  help  tap  the 
ohdects,  as  ’•hey  exisf  in  the  real  world,  into  what  they  may  be 
called  in  nni  terroinoloqy.  The  Analyzer  outputs  relevant  to 
each  aspec"  of  the  Jescription  are  also  presented  to  aid  the 
analyst  in  making  the  description  consistent  and  complete. 

'"he  explanations  of  mpl  statements  are  given  at  three  levels  of 
oroc ision: 

"■Bust"  - denotes  that  this  is  checked  by  URA  and  not  entered 
into  th“  data-base  unless  correct.  Note  the  "must" 
1o».s  not  necessarily  imply  in  this  sense  that  the 
narticular  statement  has  to  be  in  the  data-base. 

"can"  - denotes  that  a choice  is  available.  Each  choice 

seiectol  is  checked  by  UPA  and  not  entered  into  the 
data-base  unless  correct. 

"should"  - denotes  ♦•hat  this  is  not  checked  by  ORA  before  stored 
in  the  data-base  but  is  necessary  for  a complete 
description  of  the  target  system.  Some  of  these 
"completeness"  checks  are  made  when  producing  ORA 
reports  and  warning  messages  are  produced.  Others 
can  b“  made  bv  the  analyst  using  ORA  reports. 

"implies"  -denotes  the  semantic  meaning  of  the  statement. 

and  This  is  not  checked  by  ORA  nor  necessary  for  a 

"may"  complete  description.  Interpretation  is  to  be 

decided  bv  the  Problem  Definer  and  organization. 


2.  1 System  goundarier,  and  InpuJ  Output  Flow 

One  0®*  data-base  describes  one  Information  Processing  System 
and  ohlects  associated  with  it.  The  description  of  a system  can 
begin  bv  descrihinq  its  boundaries.  (Identifying  the  boundary 
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of  a syst®iii  is  not  always  easy;  consi<1erations  involved  in  this 
process  are  discussed  in  U.1  .)  This  section  describes  the  ORL 
facilities  in  specifyinq  systea  boundaries  and  flow  to  and  froa 
the  system. 


■’.1.1  System  Flow  Oh  1ects 

■"he  boundary  of  th“  tarqet  system  is  described  in  terms  of  the 

obiects  which  ^low  across  the  boundaries. 

TVPT'  - an  oh  iec*-  which  contains  data  and  flows  into  the 
tarqet  system  from  an  external  object  (i.e., 

I pj^cE)  to  an  internal  object,  (i.e.,  a PROCESS). 

OT^PtiT  - an  object  which  contains  data  and  flows  from  the 

tarqet  svstem  to  an  external  object  from  an  internal 
object  (i.e.,  a PROCESS)  to  an  external  object  (i.e., 
an  TNTFpfacE)  . 

- an  object  which  designates  a collection  of  data 

containers  and  is  stored  and  updated  by  an  internal 
object,  (i.e.,  PROCESS). 

rN?F?*'Arr  (or  PE aL- wOPtO-ENriTy)  - an  external  object  which  can 
produce  an  TVPHT,  receive  an  OUTPUT  or  be  RESPONSIBLE 
FOR  a SFT. 

PROCESS  - an  internal  object  which  can  accept  an  INPUT  or 
produce  an  OUTpnt  or  UPDATE  a SET. 


P.1.2  Systoa  Flow  Fe  latjonsh  i ps 

"'h"  verbs  in  th“  above  definitions  that  are  formal  URL 
relationships  are: 


CFN*' FATFS/Cl«'NF'’A  ted  PY 

An  TN^FFeACE  must  (;fwepA''’E  an  INPU"’  or  the  INPUT  must  be 
OF'I*'?A‘''Fr  BY  an  ■'V^FppncF.  A FPOCESS  must  generate  an  OUTPUT  or 
the  rtrpUT  must  be  GENERATED  BY  a PROCESS. 


ffcetvhs/rfcptvfo  by 

An  TNTFppACr  must  PFCEIVE  an  OUTPUT  or  the  OUTPUT  must  be 
PRCEIVEP  BV  an  INT*'pfacf.  a PROCESS  can  RECEIVE  an  INPUT  or  the 
TNPrr-  can  he  RFCetV'T  PY  a PROCESS. 


UPDATFS/Uon* 7?D  BY 
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A OFOCFSS  must  ’JPOArE  h SET  or  the  SET  must  be  TJPDAT2D  BY  a 
PROCESS. 


Pi^SPONST  PLE  FOP/PFST’ONSIPLE-  INTERFACE 

An  INT’^’E’^ACE  must  be  RESPONSIBLE  FCE  a SET.  A SET  must  have  a 
oESPCNST  BL’='- INT’=‘R’’ACE. 


2.1.3  5v st3m  "low  Syntax  anl  Semantics 

"'he  obiect'^  and  relationships  involved  in  describing  system  flow 
are  shown  pictorial ly  in  Figure  2.1.1  and  in  tabular  form  in 
"'able  2.1.1.  "^he  direction  for  reading  the  table  is  from  the 
left  obgect  to  t h®  desired  relationship  and  then  up  to  the 
nar*:iculat  obiect. 

An  INT'’P''ACE  can  OENFpaT"  any  number  of  INPUTS,  RECEIVE  any 
number  of  OUTPUTS,  and  be  PESPONSTPLE  for  any  number  of  SETS. 

An  INEU'^  can  be  SENFFATEO  by  anv  number  of  INTERFACES  (implies 
any  one  of  them  must  OFNFPA"'E  it)  and  be  RECEIVED  BY  more  than 
one  ppocFSS  (implies  that  all  of  them  must  RECEIVE  it) . 

A S’"""  may  have  any  number  of  RESPONSIBLE-INTERFACES  (this 
implies  that  all  ar°)  and  may  be  UPDATED  by  any  number  of 
PP0CF5S"5  (implies  «-hat  all  do). 

7.1. u System  Flow  Common  "gu iva ler ts  and  Usage 

•''he  cbtect't  ynes  and  relationships  correspond  closely  to  those 
in  ccmmon  usage  when  apnlie)  to  an  information  processing 
svs*^am.  The  main  difference  involved  is  that  in  most  manual 
locu ment a tio n methods,  the  name  INPUT  is  related  to  any  object 
which  is  used  by  a PFOC^SS  and  likewise,  an  OUTPUT  is  related  to 
anv  obiect  which  is  derived  bv  a PPOCESS.  In  general,  no  effort 
is  made  to  distinguish  between  different  levels  of  data  when 
■'"NeUTS  and  "'UTPUTS  are  ♦■bought  of  in  this  way. 

T'inn'''S  and  OUTPUT*^  are  the  names  for  logical  collections  of  data 
whose  values  mav  eventually  appear  on  physical  media  which 
contain  data  values  --  such  as  forms,  cards,  tapes,  messages, 
reports.  Each  individual  input  or  output  document  is  usually 
one  of  a niimber  of  instances.  The  INPUTS  and  OUTPUTS  being 
described  in  upl  may  have  multiple  instances.  In  URL  the 
emphasis  is  on  the  logical  definition  rather  than  the  physical 
and  hence,  the  media  or  the  physical  format  need  not  be 
specified. 

■"he  use  of  PFrp''’VF.E  implies  that  some  physical  process  will  be 
reguired  to  receive  or  accept  the  input  "document."  Similarly, 
OENERATFF  implies  a process  will  be  required  in  the  implemented 
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♦•arqet  system  ♦•o  physically  produce  the  OUTPUT. 


INPUT  OU'^PUT  SET  PROCESS 


IN’^FPFAC^ 

OENT-RATES 

PECEIVFS  RESPON- 
SIBLE FOR 

TNP'IT 

OENER  A'^'^D 

BY 

RECEIVED  I 

oi|-"p  UT 

s FC’^T  VEP 

BY 

GENERATED 

Ct»m 

PESPONSIBLE- 

INT’=’P  FAC'=' 

UPDATED 

ppor  ’='FS 

DECEIVES  GENERATES 

UPDATES 

’able  2.1.1 

UPL  Statements  for  System  INPUT/OOTPUT  Plow 
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^ SE’"  can  be  in'- erpr  eted  as  a master-file  or  data-base,  or  more 
broadly  to  include  very  volatile  master  files  such  as,  for 
evample,  onen-order  files.  UPDATE  implies  an  operation  in  vhich 
some  data  values  in  the  SET  are  changed.  The  RESPONSIBLE  FOR 
statement  carries  •■he  common  connotation  of  a data-base 
'•belonging''  to  soma  unit  in  the  organization. 

A ?'=' AL-HORLD-ENT  T'^'Y  (or  INTERFACE)  is  an  object  not  part  of  the 
system  being  described,  but  interacts  with  the  system  in  some 
way.  *'xamples  are;  employees,  departments,  companies,  etc. 


2.1.  S System  ^low  Ou+DUts 

"ho  PIC'^'UPE  report  (with  FLOW  option  in  effect)  can  be  used  to 
nresent  t-h°  system  flow  relationships  (RECEIVES,  GENERATES, 

‘=»‘-c.)  amom  INPUTS,  OUTPUTS,  INTFPFACES  and  PR03ESSBS  in  a 
graohical  forma'". 

"he  PPOCFSS- TNPU‘"/0UTPUT  report  presents  the  same  information  as 
described  above  for  UPOCFSS  names,  but  in  an  alternate  format. 
This  reoor'-  will  also  present  any  DESCRIPTION  statements  related 
to  ♦he  PROCESS  names. 

'=‘\o_w  Tom  pletena  ss  Checks 

'•’he  comoleteness  checks  that  can  he  made  for  system  flow 
completeness  are; 

rvary  should  either  (i)  GENERATE  some  INPUT  or  (ii) 

RECEIVE  some  OUT PU"  or  (iii)  be  RESPONSIBLE  for  some  SET. 

Every  TNPU"  should  be  GENFPA"EE  by  at  least  one  INTBPFAGE. 

Every  OUTPUT  should  be  RECEIVED  by  at  least  one  INTERFACE. 

Every  INPUT  should  b®  RECEIVED  by  at  least  one  PROCESS. 

Every  output  should  be  GENERATED  by  at  least  one  PROCESS. 

"'he  last  four  checks  can  be  made  by  using  the  DATA  PROCESS 
reoort. 

“• ? Syst  em  St  ructure 
SSlilliliSIl  2f  St  ruct  lire 

A number  of  th®  objects  in  the  description  of  systems  are 
related  to  each  other  by  one  object  being  a "component"  of  one 
or  mere  other  objects  or  "belonging"  to  it  in  some  way. 
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for  S^ruc^ure 

S'Tuc'-ur.il  relat  ionships  may  be  liefinofl  for  ore  of  two  reasons, 
stnic-ural  relationships  are  said  to  arise  from  the  "real  world" 
if  ♦■hoy  are  part  of  the  description  cf  the  tarqet  system  and  its 
associated  obiec'-s,  i.e.,  if  they  really  exist.  Structural 
rola tior ships  ar®  said  *o  be  "definitional"  if  they  are  made  for 
convenience  in  the  process  of  describing  the  target  system  but 
do  rot  exist-  for  orher  reasons.  Real  world  structure  must  be 
maint-ained  as  part  of  the  system  description  but  definitional 
relationships  may  he  discarded  when  no  Icnqer  needed. 

The  description  of  structure  permits  "summarization"  of  the 
Problem  statement  a*-  various  levels  of  the  structure  and, 
♦■horefore,  facilitates  tof>-down  or  bottom-up  problem  definition 
and  approval  at  various  levels  of  completion. 


t^epresen  tati  on  o_f  ? t r uc t ii re 

s«-ructural  relationships  are  usually  called  trees  or  directed 
ne'-wccks  and  ronressn'-ed  as  shown  in  »='ig  ure  2.2.1.  The  objects 
are  represented  by  dots  called  nodes  and  the  (structure) 
rela  t- ion  shins  by  ^h3  lines,  called  arcs,  connecting  them.  Trees 
and  networts  are  "directed"  in  that  the  nodes  are  identified  by 
the  level.  *'oi  example,  A is  a higher  node  than  B,  C or  H.  A 
node  may  have  immediate  successors  or  lower  nodes,  e.g.,  the 
immediate  successors  to  J are  E,  F and  G.  Similarly,  a node  may 
havo  imm»'diat-e  predecessors  or  higher  nodes,  e.g.,  Q has 
immediatf  predecessors  V and  P. 


2L  '^tr  uQt-ii  res 

A nod**  which  has  no  predecessors,  i.e.,  the  highest  node  is 
called  the  root  of  the  struct\jre,  e.g.,  A and  M, 


“ ' f tee  or  hifrarchi£al  structure  is  one  in  which  each  node 
except  the  highest  node  has  one  and  only  one  immediate 
predecessor  (Figure  ?.2.‘’a). 

- A directed  network  structure  is  one  in  which  each  node  except 
the  highest  node  mav  have  more  than  one  immediate  predecessor. 
Tf  the  structu’’®  contains  no  cycles,  it  is  said  to  be  ac  vclic 
(Figure  2.2.1b).  ” ~ 

A node  which  has  no  successors  is  called  a leaf  or  a tec mina^ 
node  . 


In  seme  cases,  a structure  may  contain  objects  of  different 
•■ynes,  A structure  containing  objects  of  only  one  type  is  a 
"homogeneous"  structure;  one  containing  more  than  one  type  is 
called  " non- homo gen® o us. " 
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\ terminal  noie  may  be  assiqned  to  the  highest  possible  level  or 
♦•he  lowest  possible  level,  e.q.,  noie  D may  be  regarded  as  being 
on  the  same  level  as  J or  on  the  same  level  as  E,  f and  G. 


A 


n 

0 


0 C 


D 0 


• • • 

• • 


A 

U 


r T 


c 

V 


• 9 

NO  OP 

• • • • 

• • • • 

0 0 Q 

. . 0 T 

• • • • 

• • • • 

0 0 0 0 
P SUV 


(a) 

Tree  structure 


(b) 

Directed  Network  Structure 


Figure  2.2.1 

■^ree  and  Network  Structures 


Stru  c*''ire  in  U^L 

■^n  UFI,  nodes  reoresen*-  objects  and  arcs  represent  structural 
(and  other)  relationships.  Two  major  types  of  structural 
relationships  are  available.  Data  structure  relationships 
involve  objects  which  are  data  elements  or  combinations  of  data 
elements.  All  other  structure  relationships  are  called  system 
structure  statements.  System  structure  statements  are  describe! 
in  this  section,  data  str»jcture  statements  in  Section  2,3. 

""able  2,2.1  shows  possible  nodes,  source  of  relationship,  type 
of  structure,  lowest  unit  and  level  of  lowest  unit  for  each  typa 
of  object. 
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* A collec+'ion  of  ♦■.rpes,  i.».,  a rhorescence,  is  periitted 
' Acvclic  networks 
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2.2.  1 Syst**!  St rtictu t e Qbipcts 

Collo«inq  '■ypes  of  oblects  nay  belonq  to  system  structures: 

IMTEPF ACE 

TNPnr 

OffTFUT 

PROCESS 

DonCESSOR 

S^T 


2.2.2  Skills!!!  Relat  ionships 


SUPT’AFTS  APF/PSP-"  OF 

■^hosG  s^atoments  may  be  usei  with: 

-NTFpF  aces 
IN  PUTS 
OU'^rUTS 
’’F  ^CFS  SFS 
pooc^sso^s 

^.q.,  an  INPUT  may  have  SMRPAPTS  which  are  INPUTS  or  it  may  be 
PART  OF  some  other  INPUT. 


‘JUSSE’'’  OF/SURSF"’S  AFF 

A ss""  may  be  a SURSE"’  of  some  other  SE*"  or  it  nay  have  other 
S'TS  as  SlIRSFTS. 


U'^'ILITFS/TriL'^EED  PY 

A PPOCSSS  nay  rrxLIEE  another  PROCESS  or  it  may  be  UTILIZED  by 
other  PPOCESSES. 


2.2.  ’ Sv stem  s*- rurture  Syntax  and  Semantics 

■^he  obiects  and  relationships  involved  in  describing  system 
strnC-ure  are  shown  pictorially  in  Figure  2.2.2  and  in  tabular 
form  in  Table  2.2.2. 

A s'- met  lire  defined  by  the  S npp APTS/PAPT  OF  statement  is  a 
homogeneous,  hierarchical  tree,  i,e.,  all  nodes  in  a structure 
must  be  of  the  same  type  and  any  oblect  can  be  PART  OF  only  one 
immediate  higher  noie.  A node  can  have  any  number  of  SOBPARTS 
of  'he  s ame  t ype  . 

'"he  relationship  in  a SUPSET  OF/SUPSETS  APS  must  be  homogeneous. 
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ii  i.o.  , only  SETS  may  be  SUBSETS  of  other  SETS,  The  structure  aay 

be  a network,  i.e.,  a S^T  can  he  a SUBSET  of  any  nuaber  of  other 
j sets . 

il 

relationship  ir  UTILIZED  BY/HTILIZES  must  be  hoaoqeneous, 
i.e. , only  PROCESSES  can  be  UTILIZED  by  other  PROCESSES.  The 
structure  mav  be  a netowrk  since  a PROCESS  can  be  UTILIZED  BY 
any  number  of  PPOCFSSES. 

In  general,  "subiivi 'Jing"  an  object  through  a structure 
statement  loes  not  directly  imply  that  relationships,  of  other 
types,  which  held  for  the  object  also  hold  for  its  SUBPARTS. 

’'or  example,  suppose  the  problem  statement  has  been  defined: 

IwniT  a-input; 

GEKFP>‘"FD  BY  a-rwe; 

RECFIVED  BY  a-process; 

Then  new  statements  are  added: 

TNPU'”  a-input; 

SUP  PAP  IS  a b-input , ac-input; 
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4- 

1 

4 

1 

I 

SnPPAPTS  A?P 


A *• 

p^p-r  OF  I PFOCFSSOPI  I SET  | 

♦ ♦ 

SUDPAPTS  APS  . A PART  OF  . A 

. . StlRSETS  ARE  . . SUBSET  DP 


I PFOCESSORl 


y • 

J SET  I 

♦ ---  — » 


''iqure  2,2.2 

SOHP  STPUCTUFAL  FELATIONSHIPS  EXPRESSIBLE  IN  URL 


PAPi' 
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SET  PROCESS  PROCESSOR 

T*j"t?nFArE 

PART  OF 

SUn^A  RTS 

A ?*■ 

INPUT 

PART  OF 
SUBPAPTS 

OUTPUT 

PARTS 

OF 

SUBPAPTS 

SET 

SUBSETS 

ARB 

SUBSETS 

OF 

PROCESS 

UTILIZED 

UTILIZES 

BY 

PART  OF 

SUBPAPTS 

ARE 

PPOCESSOP 

PART  OF 

SUBPARTS 

APE 

Table  2.2,2 

MRL  Stat-emen*- s for  System  Structure 


Th>=>  ^nalvrer  will  not  automatically  assume  that  ab-input  and 
ac-input  are  (;’='N  S^A""  Fb-BY  a-rwe  and  FEC’5IVED  by  a-process.  If 
the  analvs*-  wishes  to  make  this  statement,  he  should  add  this 
information  explicit ly; 

IMPn*  ab-input  ,ac-input; 

nFNFPA"»'D  BY  a-rwe; 

PFCETV’='r>  BY  a-process; 

Tn  practice  if  the  problem  had  been  defined  from  the  top-down, 
the  analyst  should  also  have  subdivided  the  INTERFACE  and  the 
PROCESS  wh®n  the  input  was  subdivided. 


System  St  ructure  Common  Equivalents  aQ  j IlSiflS 

"he  tree  structure  of  TNtEPFACSS  corresponds  to  the  hierarchical 
structure  of  most  ornani7ations . The  tree  structure  of  INPUTS 
and  OUTPUTS  is  use-^  for  convenience  in  definition. 
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nay  also  he  used  to  describe: 

a)  A form  with  many  copies,  e.q., 
INPUT:  FORM- A; 

SUBP:  FOPM- A-COPYl, 

PORPt-  A-COPY2; 

or 


b)  Docum-^'nt  '•hat  is  qenerated 

F.q. , 

OirPUT:  FOP"- A; 

SUBP:  FOPI-A-DFPT-X, 
pop r- A- OF PT-Y, 
FOPV-  A-nFPT-z; 


and  qoes  to  different  places. 


(names  chosen  according 
to  puroose  of  carrier 
or  final  destination) 


A PPf'CFss  has  two  types  of  structures.  The  one  developad  by 
nsino  SU  PPAP'^'S/P  AP”  CP  may  be  used  for  top-down  definition  of 
the  system.  I'  may  also  be  used  to  represent  the  structure  of 
modules  in  a proaram  (e.q.,  SLOCKS  and  PFOCFDUPES  in  a PL/1 
oroqtam).  In  both  cases,  a tree  structure  is  appropriate. 

•^he  structure  of  PFOrpsSFS  developed  usi.ng  the  UTILIZED/ UTILIZES 
may  be  used  to  reprasert  ''calls"  to  program  or  a PROCESS  which 
is  used  (i.a.,  called  from)  in  a number  of  processing  sequences. 


2.1.P  System  Structure  Reports 

Fopf^aTTcp  npopi^pf,  «:7;it'FpeNT  shows  the  immediate  structure  in 
which  an  obdect  is  inyolyed,  i.e.,  all  those  objects  of  which  it 
is  PAPt  OF,  sunssr  OF  or  UTILIZED  PY  and  those  that  are  its 
SURP»PTE,  SUPSFTS  or  it  UTILIZED. 

■''he  PICTtnE  report  (with  the  STFUCTUPE  option  in  effect) 
presents  the  SPBPAPrs/PAPT  OF  relationships  for  INPUTS,  OUTPUTS, 
IN't'=* RFAC FS  and  PROC^SSFS  in  a graphical  format  of  the  immediate 
structure  of  a particular  object. 

The  ST^uc^UPF  report  presents  the  same  information  but  in  a list 
format  which  displays  all  levels  in  the  system  structure.  (The 
reports  listed  above  only  presents  the  structure  levels  directly 
above  and  directly  below  the  designated  object.)  Loops  in  the 
system  structure  ar“  detected  by  this  report, 

"•h-*  STPnCTUPE  report  presents  only  PART  OF/SURPARTS 
ralatiopships.  UTILIZ^S/UTILIZFD  RY  and  SUBSET  OF/SUDSETS  OF  is 
only  shown  in  the  FOFZATTrn  PPOBLFF  S'^’A?  EMENT . 


”*.2.6  ^st^m  Compl eteness  Checks 

All  the  completeness  statements  in  System  Flow  apply  to  each 
SURPART  as  it  is  defined. 
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suhd  i vin  ior , ^'hp  totality  of  statements  about  the 
'^'rnr’APT?^  must  ho  consistent  with  he  statement  about  tha  obiects 
♦^o  which  •■he  PAP“S  belong. 

> strurturo  of  TNTfP  PACES,  since  it  represents  the  real  world, 
cannot  he  checked  for  comple teness,  i.e,,  whether  the  lowest 
Ipvel  nodes  hav®  been  defined,  unless  terminal  nodes  are 
desiqnated  by  an  aporopriate  ATTPIBUTF. 

A structure  involvinq  t^ppts /OtJ'^'PUTS  is  not  homogeneous  since 
•■he  lower  nodes  reoresent  tIFO'IP  or  ELEMENTS.  The  following 
rules  should  he  observed: 

■')  All  I"?!!'’’  structures  having  STiBPAPTS  should  terminate  in 

INPUTS  which  have  a media  ATTRIBUTE  (whose  value  can  be  "TD 
BE  OE"'EF  MINED,"  TBD)  and  which  contain  data  values. 

2)  An  INPU'''  should  not  have  both  a SUBPART  statement  and 

CONTAINS  sta^’ement.  Only  the  lowest  level  INPUT  should 
CONTA^’N  FLE.'1’''NTS. 

?)  All  OUTPU""  structures  having  SUPPARTS  should  terminate  in 
rUTPUTS  which  have  a media  ATTRIBUTE  (whose  value  can  he 
"T'O  '•E  DETE  P.MIMFP, '•  TBD)  and  which  contain  data  values. 

U)  An  outot!t  should  not  have  both  a SUBpART  statement  and  a 
CONTAINS  statement.  Only  the  lowest  level  OUTPUT  should 
contain  ELE MEN'S. 

When  a PPOC’SS  structure  is  defined  using  PARTS  OF/SUBPARTS  ARE 
each  PROCESS  may  contain  SU3PARTS  as  well  as  some  PROCEDURE 
s«-atement.  A PROCESS  which  the  analyst  does  not  wish  to 
subdivide  further  should  be  designated  a terminal  PROCESS  by  the 
use  of  an  ATT'?TBUTE  sta^-ement. 

A Ppnc^SS  which  does  not  have  any  SU3PAPTS,  should  have  a 
PPOCEDUPE  St  a tern  en*-. 


-•  ^ pat  a S»  r uctii  re 

» s was  descrihod  in  Section  2.2,  various  structural 
relationships  can  he  sp^cifiel  in  DPI  to  relate  "components"  of 
the  sys<-em.  When  the  structual  relationships  being  specified 
are  arplicable  to  data  objects,  the  structures  presented  are 
termed  "data  S'^ructu  r es.  " 


2.1.1  Pa^  S»  i;uc  turn  Ob  lects 


2.1. 1.1  Pa^a  Def  jnit ion 

'he  basic  objects  for  def  ini  nq  data  are  ELEMENTS  and  GROUPS. 


PART 
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PL 't!*'*  ^ 

An  SIEM'^N’''  is  '■h>i  basic  unit  of  information  and,  therefore, 
cannot  bt  suhiividpd.  An  ELEMENT  is  used  to  define  an  ohiect 
which  may  ♦•airp  on  a value.  For  example,  if  "employee 
information"  was  defined  to  he  an  ENTITY,  it  would  not,  in 
itself,  have  a value.  The  ELEMENTS  making  up  "employee 
information"  such  as  "age,"  "sex,"  "salary,"  etc.,  might  have 
values  for  a particular  instance  of  "employee  information." 


gpouF 

A SFOnp  is  used  to  define  a collection  of  ELEMENTS  and/or  other 
GROUPS.  This  is  done  so  that  the  information  names  can  be 
thought  to  b«>  related  within  the  larger  collection  of 
information  (inputs,  OUTPUTS  or  ENTITIES).  The  name  of  the 
GROUP  can  bo  thought  to  be  synonymous  with  the  names  of  the 
Gnonpts  comoononts.  In  the  example  of  "employee  information," 
♦■he  "name"  of  the  “mplovee  may  be  defined  as  a GROUP  where  the 
constituents  of  the  Gnoup,  "first  name,"  "middle  initial," 
"surname"  may  b®  defined  as  ’='LEMENTS.  The  use  of  GROUPS  is 
primarily  a no'-ational  convenience. 


. d . 1 . 2 Uef  initjon  of  Collections  of  Data  Value^ 


•"he  defini*-ion  of  an  ELEMENT  or  a GROUP  is  like  a 
a word  in  a dictionary.  The  definition  specifies 
♦•o  be  used  bu*-  does  not  give  the  instances  of  its 
paragraphs,  sen'-ences,  etc. 


definition  of 
how  a word  is 
use  in  books. 


Tn  describing  information  systems,  it  is  necessary  to  have  types 
of  obgocts  which  can  represent  the  things  in  which,  or  on  which, 
instances  (valu’^s)  of  ELEMENT'S  appear.  In  UF.L,  there  are  three 
such  types  of  objects:  INPUT?,  OFU-pUTS  and  ENTITIES.  The 
diffcrenc-3  among  these  of  collections  is  related  to  their 

role  in  the  targ‘»t  sys'-em. 


An  ivpu"'  is  a collection  of  information  produced  external  to  tha 
target  system,  bu'-  used  by  the  target  system.  For  example,  in 
an  inventory  svstem,  a customer  order  may  be  considered  an  INPUT 
to  the  sys'em. 
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I 

i OU'^PU'^S 

! Bn  c'U’'‘PUT  is  a collsctior.  of  information  produce<1  by  the  target 

systfap,  bu'"  which  is  used  external  to  the  system.  For  example, 
j the  payrhertrs  produced  by  a payroll  processing  system  could  be 

thought  of  as  onTPU''’S  as  they  are  eventually  used  by  employees 
outside  of  the  system.  Cnee  the  collection  has  left  the  system, 
no  further  reference  may  be  made  to  it. 


ENTITIES 

An  ENTI'^'Y  is  a collection  of  information  which  is  maintained 
internal  to  the  system.  ENTITIES  are  initially  "produced"  and 
then  "main'-ained '*  using  information  from  INPUTS  and  then  OUTPUTS 
are  produced  us  i no  information  from  ENTITIES  (and  other 
sources)  . "''he  "employee  information"  mentioned  above  would  be 

defined  as  an  ’^'NTTTV  . 


2.1.  ■’.3  °ela  t ion  ships  Among  Col  lections  of  Inf  ormati^on 

Collections  of  information  maintained  internal  to  the  system 
(EN'^  I'^'IE  <?)  are  often  "related"  to  each  other  in  that  there  is  ! 

information  which  is  not  inherent  to  either,  but  associated  with  i 

both.  In  the  example  of  a warehouse  stock  control  system,  1 

information  about  inventory  items  may  be  related  to  information  j 

about  their  suppliers,  etc.  RELATIONS  are  used  to  describe  | 

these  logical  connections  among  ENTITIES.  j 


2.1.2  Uata  Relationships 

’’he  rela  ion  shins  '•hat  can  be  specified  for  data  structure  are 
shown  in  tabluar  forms  in  Table  2.3.1  and  Table  2.3.2.  This 
information  is  also  presented  in  Figure  2.3.1  in  a graphical 
format. 
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Structure 
Statements 


1 . SUBSETTING-CRITERIA 

2.  IDENTIFIED 

3.  ASSOCIATED -DATA 

4.  BETWEEN 


1161  Pf^/ll'inCS/UPl  USER'S  MAN'JM, 


72 


r 


*‘iau re  2.3.1  | 

rONSISTS  O’'/ COM"  A IKE  D TM 

" SE"  may  CONSIST  of  ENTITIES,  or  INPUTS,  or  OUTPUTS.  Likewise, 
an  INPUT  or  an  OUT''UT  or  an  ENTITY  nay  be  CONT^NED  in  a SET. 

BELA'’'Fr)  TO  VT  .A/UETW’'EN 

An  ’='NTI'’’Y  nay  h=>  RELATED  to  another  ENTITY  VIA  a qiven  RELATION. 

A M’'I.A"IOM  may  be  defined  fo  exist  PETWEEN  two  ENTITIES. 

SUMS  STTT '>S-C  ? ITS  R I A/S  MRS  ETTI  NO- CRITERION 

A OPOUP  or  ELEME»IT  may  he  St>BSET’’’INq-CFITERION  for  a SET  and  a 
S’'T  mav  have  OCOUPS  and/or  ’'LEMENTS  which  are 
CRITERIA  . 

TD’'NTI»'IEC  RY /I  DEN"!  FTPS 

An  EMTT"V  may  be  IE  EN ’’’I’' I El  BY  a GROUP  and/or  ELEMENT  an  d a 
GROUP  or  ELEMENT  IDEMTiET’'S  an  ENTITY. 

A3SnC"ATEr)-DA'''& /ASSOC  lA^EB  WITH 

A RRIATION  may  have  GROUPS  and/or  ELEMENTS  as  ASSOCI ATED-DATA  . 

Also,  a GROUP  or  ELR^ENT  may  be  ASSOCIATED  WITH'a'RE LATI ON . 

VAL”’"  IS 

An  ELEMENT  mav  have  a particular  VALUE  or  ranqe  of  VALUES 
associated  with  it. 

?,  3.  3 Dald  SilliSLJilS  semantics 

A SY STEM-PAR  A'*’'"”  SR  or  numerical  value  may  be  specified  in  the 
CONSISTS  ;?»atament  or  SETS,  INPUTS,  OUTPUTS,  ENTITIES  and 
spanrc  .^or_o‘-e  ♦•he  number  of  instances  of  the  components  for  a 
liven  ins*’a"ce  of  ♦he  con»-aininq  obiect. 

An  'W-I-T,  INP'!"  or  OUTPUT  mav  CONSIST  of  any  number  of  GROUPS 
*n  I /er  "t 

I ■>'  arv  number  of  INPUTS,  OUTPUTS,  or  ENTITIES, 

• jm**  ' ♦•  ir  of  'hea*  obdect  ♦ypes.  Also,  a SET  may 
. ...  - ,»  •rnie«  ml /or  Rl**?N'’‘Sas 
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An  cm  he  TnFKTTPIFD  by  any  number  of  GROUPS  and/or 

EL5MF1TS,  and  be  R’=’LA'''EO  to  any  number  of  ENTITIES.  However, 
^or  each  unique  pair  of  ENTITIES,  a unique  RELATION  must  be 
defined,  ^.q,,  if  a PELATION  between  El  and  E2  is  defined  as 
”1,  a R'='lA'"TON  between  El  and  F3  cannot  also  be  called  R1. 

A •>”lA"'TON  may  onlv  b**  defined  to  he  BETWEEN  a single  pair  of 
EN-'ITirc,  jv  different  RELATION  Hus'-  be  defined  for  each  ENTITY 
oair.  A RELA''’I0N  may  have  any  number  of  GROUPS  and/or  ELEMENTS 
as  ASSOCIA'^ED-DATA. 

A GcoTP  may  he  rONTAINER  in  any  number  of  GROUPS,  ENTITIES, 
INPUTS  and/or  cutrUTS.  A GROUP  may  also  IDENTIFY  any  number  of 
ENTITT’^'5,  he  SUBSF'"'^  ING-CRT’"ERTON  for  any  number  of  SETS  and  be 
AS?0CTA"-^U  WIT"  any  number  of  PEIA^-ICNS.  In  addition,  a GROUP 
may  COnsT'^"'  of  any  number  of  GPOUPS  and/or  ELEMENTS, 


INPUTS  oTrrpnrs  set 


ENTITY  GROUPS  ELEMENTS 


IMPU-’S 

CONT AINEC 

CONSISTS 

CON  SI  STS 

IN 

OF 

OF 

rT»T" 

COV^ATNFr 

CONSISTS 

CON  SI  STS 

TN 

OF 

OF 

SF”  CONS’ 

STS 

CONSISTS  CONSISTS 

OF  OF 

CONTAINFB 

CONSISTS 

CON  SI  STS 

IS 

OF 

OF 

GROUPS  COSTA 

TV- 

CONTAIN-  CONTAIN- 

CONSISTS 

CONSISTS 

r r> 

IN 

IN  EP  IN 

OF 

OF 

CONTAINED 

IN 

- **  F ^ 

rONTA 

I'I“ 

CON^ATN-  CCNTAIN- 

CONTAIN- 

FT) 

IN 

Er  IN  ED  IN 

ED  IN 

Tabic  2.3.1 

rp 

S*-a 

♦•emertr.  for  Data  STRUCTURE 

Reiat  ionships 
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SE* 

FN"'I"'Y 

RELATION 

GROUPS 

ELEMENTS 

S F*” 

SUBSETTI NG- 

SUBSET- 

CRITERIA 

TING 

CRITERIA 

FN*'”^  TIFP 

FELATEO  TO 

R/VIA 

IDENTIFIED 

IDENTI- 

BY 

PIED  BY 

PELA  TTON 

BF^’WFEN 

ASSOCIATED- 

ASSOC- 

DATA 

lATED 

DATA 

GROUPS  SURSFT*!  !JG- 

IDENTIFIES 

ASSOCIATED 

rr  J-’eR  ION 

WITH 

FLEM^NT  StmsPT'PING- 

IDENTIFIES 

ASSOCIATED 

VALDES 

CP ITPP ION 

WITH 

Table  2.3.2 

i UHL  Dsfinitional  S'la tenent. s Relating 

' S’^rS,  ENTITIES,  BFLATIONS,  GROUPS  and  ELEMENTS 

An  ELEIFN'!’  may  be  CONTAINEn  in  any  number  of  GROUPS,  ENTITIES, 
INPUTS,  and/or  OUTPUTS.  An  ELEMENT  may  also  be  used  to  IDENTIPT 
anv  number  of  -N'"Ti’lFS,  be  s upSET'^'ING-Cp  ITER  ION  tor  any  nuaber 
of  SFTS,  and  b«  A'-SOCIATED  anv  number  of  RELATIONS.  In 

adlitior,  an  rT.^MPNI  mav  tate  on  a particular  numerical  fALUB  or 
a ranqo  of  VALUES. 

2.3.U  T^^a  Structure  Common  pquiva lents  and  Us^qe 

"h  » names  URL  user;  ^o  define  data  structures  are  very  close  to 
SOS'-  terminolouv  in  this  fieii.  For  example,  ELEMENTS  are  often 
referred  to  as  "items,"  "data  items,"  or  "fields"  in  other  data 
structure  t ar min oloi ies . GROUPS  are  sometimes  referred  to  as 
"seumerts"  or  "data  aguregates."  ENTITIES  are  sometimes  called 
"records"  and  SE"^*^  sometimes  "files"  or  "data-bases." 

■'f  a SF""  is  inton  led  to  represent  a "file"  where  ENTITIES  ace 
"records,"  the  following  options  are  available  in  describing  the 
file  structure. 

al  If  the  S’"-  CONSISTS  of  onlv  one  type  of  ENTITY,  then: 

- ENTT"’Y  occurences  within  the  SET  may  be  ordered  and  so  a 

FFI  A'”TON  to  represent  this  ordering  may  be  defined.* 

- EwTI^y  occurrences  within  the  SFT  may  not  be  ordered.  A 
PSLA'"''ON  to  represent  this  need  not  be  defined. 

* If  more  than  one  FFLA'^ION  is  to  be  defined  for  ENTITIES  within 

a given  SE",  a 3 (which  is  a SUBSET  of  the  given  SET)  should 

be  defined  For  each  FEIATICN. 
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- FNTITY  ocrarrences  may  RELATED  to  each  other  based  on 
SOI"**  criteria.  A RFLATTCN  should  be  defined  to  describe 
this  relationship. 

b)  Tf  the  SET  CONST  S'-S  of  more  than  one  type  of  ENTITY: 

- occurrences  may  be  ordered.  A RELATION  should  be 
defined  for  each  ordering.  » 

» ’'NTTTY  occurrences  may  not  be  ordered. 

- ^NTTTY  occurrences  may  be  RELATED  to  other  ENTITY  types 
(for  each  other).  A RELATION  should  be  defined  to  describe 
each  of  these  relationships. 

"•he  IDENTIET^S  sta^-ement  for  GROnPE  or  ELEMENTS  may  be  jsed  to 
define  keys.  It  is  meant  that  the  designated  OROUP  or  ELEMENT 
may  te  used  when  searching  for  a particular  "NTITY  (record) 
occii  c ren ce. 


HOW  -^n  (1?*:  "HE  oELA^rON  SECTION 
"0  EYPN^-ss  tPCICAL  CTNNEC'ION  IN  PROBLEM  STATEMENT 


a) 


h) 


Eetermine  symbolic  (UFL)  name  for  the  RELATION.  It  is 
reromaended  ♦hat  the  name  denotes  the  type  of  connection 
that  it  will  supcly. 

Determine  which  ENTITIES  the  RELATION  connects  and  the 
diroc^ion  of  the  connection.  Use  the  URL  BETWEEN  and 
CON NEITI VT" Y statements  to  state  this  information. 


'■xam  plo ; 

'"uonose  the  analyst  has  the  following  (logical)  view  of  his 
data  : 
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♦ 


♦ 


I DEPAPTBENT 
I 

r 


T 

I 

I 

I 

I 


♦ - 

T 

NT 

♦ - 

T 

I 

T 

HOP  PLY 

T 

I 

SALARIED 

I 

I 

FFPI  nr^<i5 

T 

I 

EMPLOYEES 

I 

T 

♦ - 

T 

I 

♦ - 

I 

- ♦ 

MPT.  st^»-eit®nts  That  thp  two  DELATIONS  are: 

T Atl  ON  -1  ppt-  to-  h our  ly-ee  ployees ; 

BPTMSEN  lept  AND  h our ly-ea ployees; 

CONNECTIVI-y  I s 1 "*0  ■ait-;\ept-hourly-eeployeer\t; 

PETATTON  ''PDt-to-3alarie<1-®«ployees; 

B*'TWPyN  1ept  AND  sa  larip^-piiployeps; 

CONNFCTIYTTY  is  1 "'0  lax-lept-sa  laried-eeployeent; 

51“E  i 

a)  fottirain®  if  any  data  han  been  defined  to  be  CONTAINED  in 

both  FNTITT«‘S.  Analyze  this  data  and  detecaine  ENTITIES  or 
AFSOCTATID  DATA  statcmerts. 

h)  trteraine  if  any  additional  data  is  needed  to  describe  the 
FFLATTON  and,  if  so,  this  data  should  be  defined  as 
ASFOCT»TFb  DATA. 
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'■x^m  pie: 

A -sore  refine-l  and  detailed  logical  view  of  the  data  given  above 
miaht  be: 


T 

T 

T DEPAP7HENT 
I 

T 


I 
I 
I 
I 
I 
• ♦ 


I lastdato  I 
leunloyf'e  hir^dT 
lor  terminated  I 


t-.-  — ...-.-..-4. 


r HOi>PLY  " 
T *‘M  ri.ov  I 


4.. ..-.- .......4 

I last  date  1 
lerployee  hired! 
lor  teriinated  I 

4..  ....... .-...4 

4. ...... ....4 

I I 

I SALAFIED  I 
I EMPLOYEES  I 
I I 

4.... .... ...4 


a)  re«- omi  r.o  the  f^-lattcn's  caFTTNALITY 

h)  ret  ermine  the  7FOCES5FS  that  utilize  the  FPLATION  and  thosa 

r®t'CE?SFS  that  adft,  delete  or  modify  the  connection 
occurrences  ot  the  PFI.ATION. 


’esu Its: 

""he  analyst  ^as  information  that  is  required  for  physical 
design.  There  is  a ccnnection  between  the  prograaaing 
requirement  and  the  data-base.  The  data-base  nay  have  to  be 
revised  to  be  recent ive  to  the  processinq  restrictions. 

*'or  an  example,  see  PELATION  Definition  Form, 


2.  3.  S DaM  5t£yClllE£  Outputs 
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The  rCNSIS^S  ro»5T>AF:sON  PFPORT  presents  the  lowest  level  lata 
oblects  (usually  EI.Ef^FKTS)  in  the  data  structure  of  the  data 
oh1ec«-s  used  as  input  to  the  report.  This  infornation  is 
presented  in  matrix  form  with  several  redundancy  and 
completeness  chock  dlaanostics  in  a summary. 

The  CONSISTS  PEPOPT  presents  data  structure  at  a given 

level  relative  to  the  data  objects  used  as  input  to  the  report. 
For  example,  if  an  ENTITY  name  is  used  as  input  to  the  report 
and  the  COVSIS'""  parameter  is  specified,  all  DROOPS  and/or 
ELEtlFN'^S  the  ENTITY  CONSISTS  of  will  be  presented.  If  the 
’‘NTI'^Y  name  and  th®  CON'^AINED  parameter  is  specified,  all  those 
‘^E'^S  ♦he  rvTTTY  is  CONTAINED  will  be  presented.  All  information 
in  the  report  is  oresented  in  a matrix  format. 

The  covTmN'"S  proo»*  presents  the  data  structure  at  all  levels 
For  a given  da*a  obdect  as  incut  tc  the  report.  The  CONTENTS 
pppopi  presents  the  data  structure  going  down  to  the  lowest 
specified  in  the  problem  statemenf. 

•ho  IDENTIFTE9  INPO^KATION  FEPOPT  presents  those  ELEHENIS  and/or 
ovonpe  defined  as  IDENTIFIERS  for  a particular  ENTITY  or 
presents  fhe  enT-ITFS  IDENTIFIED  by  a particular  OROOP  or 
PlENFNT.  This  information  is  presented  in  a matrix  format. 

•he  four  reports  are  summarized  in  Table  2.3.3. 


1 


i 


I 
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COMSTSTS 


COSPiPIfQN 

CQN'"EN"'S 

CO^I^S  EATPtX 

consist”  containeB 

FPS 

CPT* 

y 

X 

NO 

X 

FN"’T'»' Y 

X 

X 

X 

X 

TN^UT 

X 

X 

X 

X 

ortTPll"' 

X 

Y. 

X 

X 

GROUP 

X 

X 

X 

X 

FLE"  EN"" 

X 

X 

PON  id 

highest 

T EV*"! 

ID 

CCL 

I D 

ROW 

ID 

OBJECT 

LP VEST 

NO''  E D 

NFS! 

HIGHER 

NODE 

0 

‘ ♦ • • • 

H'-GHFST  1 

1 • • • 

LOHE*^  1 

1 

• 

NODE  1 

1 0 . . 

NODE  1 

1 

• 

] 

• 1 

1 

9 

1 

1 

1 • • 

1 r 

• 1 

• I 

1 

• 

• 

, . . . 4 .----4 

nr'*.  0 

0 

’’ABLE  2.1.3 


2.3.f  D«^  S<~ ruc»iir'»  Cmple'-.eness  Checks 

Ml  SFT*?  shaull  "ev“  r.  ♦'ii  I ly  " consist  of  INPUTS,  OUTPUTS  or 
'=’N'"TTI'S  . 

All  INPHTs  ;jt  the  lowest  level  should  consist  of  GROUPS  and 
FIi:»FNT?.  Any  Gpnnoc  should  be  reducible  to  ELBHENTS. 

ALl  nrTPMTS  at  the  lowest  lavel  should  consist  of  GROUPS  and 
’’lE'-ENTS.  Anv  Gnoripc  should  be  reducible  to  ELEHENTS. 


2.U  tiata  pe I.  i vat  ion 

An  information  proressinq  system  exists  to  process  data,  i.e., 
to  produce  values  of  data  elements,  or  groups  of  data  elements, 
from  values  of  other  data  elements  or  groups.  This 
transformation  is  known  by  different  names  such  as  process, 
procedure,  function,  operation,  activity,  etc.  In  URL  the  term 
PPOCE'S  is  tisei. 

""ho  term  "data  derivation"  includes  the  actions  of  USING, 
UPDATING  and  OERTVI^'G  data  obdects.  The  data  objects  that  are 
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involved  can  be  IvpfrTS,  OUTPUTS,  SFTS,  ENTITISS,  GBOOPS  ind 
FLEM . 


2.4.1  Data  Derivation  nhlect s 

The  oblectf?  involved  in  data  derivation  are; 

ppPCFSS 

IPFDT 

DU  'npuT' 

Dporp 

ELEF’IN'" 

P^LA’^TCN 
CT  ASST  FICA'tlOV 
SFCUPTT^-ACCFSS-P  TOUTS 


2.4.2  Da^a  2££iY3ii2r  ,P“lationships 


DSFS /nsPD 


UODA  TF5/UP''A  ?'> 


n'^PT  VIS/D'^TV’D 


- A OPOCFSS  may  USE  a SET,  INPUT,  ENTITY, 
OPCUP  or  FLEMENt.  Likewise,  a SET, 

TNPU-t,  entity,  group  or  ELEMENT  » av  be 
USED  by  a PPOCESS  . 

- A PROCESS  may  UPDATE  a SET,  ENTITY, 
GPOUP  or  ELFMFNT,  and  a SET,  ENTITY, 
SPOUP  or  ELFFFNT  aav  be  !i.PSAJfO  by  a 
PPOrESS. 

- A PPOCFS'  may  DEF^VE  a SET,  OUTPUT, 

GROUP  or”  ELEMENT,  and  a SET, 
OUTP'J"',  *‘NTITY,  GPOUP  or  ELEMENT  say  be 
OFflTED  ty  a PPOCESS. 


•AIN-ATN  'NTAINfO  - A PROCESS  may  M AINTAIN  a RELATION,  and 

a PFLA-tiCN  may  be  MAINTAINED  by  a 
PPOCESS. 


f’'’OCErU»F  - A PROCESS  may  have  a P£2££22£i 

associated  with  it.  The  PPOCBDURE  is  a 
comment  entry  and  nay  consist  of  any 
text. 


DFRiy atton 


CLASSIFTCATTON 


- A RELATION  or  SET  nay  have  a fiSMI&IISfi 
associated  with  it  in  the  fora  of  a 
comment  entry. 

- A data  obdect  may  have  a 
CLAEST’»ICAT10K. 


‘'ECUPTTY-ArCFSS-PrGHTS  - A PPOCESS  oc  PROCESSOR  a ay  have 
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SFCURI7Y-ACCESS-P  IGHTS . 


?.U.?  Data  Dprivat  ^or  f^ntaj  an  d FeBantics 

"I’hp  obircts  an^  rpla  t ion shi p s involved  in  describinq  "da 
derivation"  are  shovr  pictorially  in  Figure  2.4,1  and  iti 
form  in  Table  2.4,1.  Table  2.4,2  shows  how  the  differen 
of  obipcts  can  a ooea  r in  the  data  derivation  stateaents. 
2.4.1  contrasts  the  syntax  and  semantics  of  the  Systea  F 
Ftatemer.ts  (P^CFIVEF  and  GEMEPATE!?)  with  that  of  the  dat 
derivation  sta’^ement  s. 

Whenever  INPH-",  onTTUT,  pntity  or  SET  are  used  in  a data 
derivation  statement  , these  obiects  are  interpreted  to  a 
data  values  contained  in  them. 

A PROCESS  may  USE  any  number  of  INPUTS,  SETS,  ENTITIES, 
an  1 ElEMENTS.  "In  optional  UPDATE  or  DERIVE  clause  can  b 
in  coninnction  w i*-h  the  USE  statement  in  the  following  i 

USES  El  TO  DERIVE  E2: 

Where  F?  is  any  number  of  da*-a  obiects  that  can  be  DERIV 
PROCESS. 

A procFSS  can  unoATE  any  number  of  SETS,  ENTITIES,  GROUP 
?I.EMEN"'S.  An  optional  USING  clause  can  be  used  in  conju 
with  the  UPDA“'^  statement  in  the  following  manner: 

update^  E1  USING  E2; 

Where  ’=‘2  is  any  number  of  data  ohjects  that  can  be  USED 
PROCESS. 

A nrocES'?  car  np^ivF  any  number  of  OUTPUTS,  SETS,  ENTTTI 
GROUPS  ani  *’LE!'EN"'r.  An  optional  USING  clause  can  be  us 
condunction  with  the  DFPTVF  statement  in  the  following  a 

DEPIVES  E1  USING  E2; 

Where  E?  is  any  number  of  data  obiects  that  aay  be  USED 
PROCESS. 

An  INPU"-,  SET,  FN'^ITY,  GF'^UP  or  ELEMENT  can  be  USED  by  a 
number  of  poQC^'SSFS.  An  optional  DERIVE  or  UPDATE  claus 
used  in  coninnction  with  the  USED  statement  in  the  folia 
mann  er : 

PS’='n  BY  PI  Tc  DERIVE  E2; 

Where  E2  is  anv  number  of  data  obiects  that  can  be  DERIV 
PROCESS. 


ta 

t abular 
t types 
Table 
low 
a 


ean  the 

GROUPS 
e used 
anner : 


ED  by  a 

S and 
nc  tion 


by  a 


ES, 
ed  in 
a n ne  r ; 


by  a 


ny 

e aay  ba 
wing 


ED  by  a 
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I 

4— - 

1 

! 

1 

♦ 

1 

ENTITY  1 

1 

SET  1 

1 RELATION 

1 

\ 

1 

1 

1 

1 

• 

USES  tn 

. USES  03 

• 

• 

USES  U2 

. OSES  U2 

• 

• 

DERIVES 

ni 

. DERIVES 

U1 

• 

• 

UPO  AT’i'S 

ni 

. UPDATES 

U1 

. KAINTAINS 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• • 

♦ ♦ ♦ 


1 

I 

I 

I 

IN  OPT  1 

1 

\ 

I 

PFOCVSS  1 .. 

I OUTPUT 

I 

USES  0 2 
OS  vs  n ? 

• 

• 

vs  '»1  . 

1 

DERIVES  01 

. 

n udA” 

« 

• 

• 

• 

. OSES  03 

ES  'M  . 

. USES  02 

nsEs 

02 

. DERIVES 

U1 

USES 

0 3 . 

. UPDATES 

01 

« 

I 

GROUP  I 

1 

1 

\ 

ELF^ENT  I 

1 

1 

f 

» 

1 

I 

U1,  *)2  an-l  H3  arfl  on  t ion  a 1 

ff*  usina  EL*'KKV'T',  '^prup,  ENTirr  and  IMPOT 

n2  to  derive  ELE'IFKT,  nsonp,  EN'^ITY,  SET  and  OUTPUT 

U3  ♦•o  UDdate  FLE»1EET,  OPOUP,  ENTITY  and  SET 


Eiqure  2.4.1 

nPL  STATEMENTS  POP  DATA  MANIPULATION 
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Chi ect 
Name  in 
Statement 
Sect icn 


’’'yne 

INT’HT  OUT 

PUT 

SET 

ENTITY 

INPU*^ 

T’O 

DEPIVF* 

TO  DFPIVE/0PDATE3 

TO  DERIVE /UPDATE* 

OriTp  yT 

TSTNG* 

USING* 

USING* 

SE"" 

USING  * 

TO 

PFFTVE3 

TO  DFFIVE/nPDATE3 

TO  DERIVE /UPDATE* 

USING* 

USING* 

entity 

USING* 

mr) 

peftve* 

USING* 

USING* 

TO  PEPIVE/UPDATE3 

TO  DERIVE /UPDATE* 

GROMP 

USING  * 

TD 

DFF7V-3 

USING* 

USING* 

TO  PFPI VE/UPDATE* 

TO  DERIVE /UPDATE* 

'=-LE*1  EN'" 

U'JTVG* 

'I'O 

pprj  V’^ 

USING* 

USING  * 

TO  DFPI VE/UPDATB* 

TO  DERIVE /UPDATE* 

or F'S 

USING  ^ 

PF”  I VT'J 

PFPTVFS 

DERIVES 

*"0 

PEPI VF" 

US'S 

USES 

UPDATES 

UPDATES 

USINGS 

USINGS 

TO  PEFIVE/UPDATF* 

TO  DERIVE /UPDATE" 

'’FL''Ti^v 


ELEMENT 


INPUT 

TO  DFRIVE/UFCATE* 

TO  DERIVE/UPDATS 

OU'"PUT 

USING  ♦ 

USING* 

SE"" 

TO  PEPIVF/UPDATE* 

TO  DERIVE/UPDATE* 

USING* 

USING* 

PN*'T  TY 

USING* 

USING’ 

TO  DEPIVE/OFDATE* 

TO  DERIVE/UPDATE* 

GT'OUP 

USING* 

USING* 

TO  DEPIVE/UPD ATE* 

TO  DERIVE/UPDATE* 

ELEMENT 

USING  * 

USING* 

TO  PERI VS/UPCATE* 

TO  DERIVE/UPDATE* 

POOCESS  MAIN-'AINS 

DEPTVFS 

DERIVES 

nSE'5 

USES 

UPDATES 

UPDATES 

USING  » 

USING* 

TO  DERIVE/UPDATE" 

TO  DEPIVE/UPDATB" 

(see  following  page 

for  footnotes) 

•^abl  e 2.  . 1 URL  S 

tatements  pel  a ted  to 

Derivation  Definiti 
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PP  OC^P  P 

TMPUT 

nr  vp  T Y 

OUTP  fj-r 

PEPIVED 

BY 

USED  BY 

up  DATED 

BY 

D''PIVED 

BY 

'VTTTY 

DEPTVED 

BY 

UPDA'^'^D 

BY 

U'JED  BY 

PELA  •^lOK 

rATV'^ATNFn  BY 

GFonp 

PEPTVFD 

BY 

nPDA'"ED 

BY 

USED  BY 

ELEKEN*^ 

OEPIVED 

BY 

flPOATED 

BY 

USED  BY 

’'POCPFS 

UTILIZ  FS 

U’"TLT7.FD 

BY 

Table  2.4.1 

'JFL  5*‘at*»m?p^s  P?lated  to  Derivation  Definition 

( Continued) 

»oo^-  notes: 

5 tised  in  con  1unc:*-ion  with  the  fJSFC  "Y  statement. 

^ Usfd  in  con  jiinct  io  p with  the  DERIVED  BY  statement. 

^ nsed  ir  conlunction  with  OFPTVSD  BY  and  'IPDA^EO  BY  statement. 

^ Used  in  co n -junction  with  n^PIVES  and  UPDATES  statement. 

* Used  in  cor.dnnction  with  USES  s-’-atement. 


P«p 


rfp  o'OU'REWFNTS  LAUGUAGE  flAiHAL 


90/.1TJLTICS/DPI  nSEP'S  MANUAL 


USES 


FLF  MEN*’’ 

GROUP 

INPUT 

OUTPUT 

ENTjry 

SET 

ri??S 

X 

X 

X 

X 

X 

TO  DERIVE. 

y 

X 

X 

X 

X 

USES  TO  UPDATE 

X 

X 

X 

X 

X 

ppoi  VFS 

DERTVES/nSTNO 

Y 

X 

X 

X 

X 

UPDATES 

UPDA  TFS/USTNr, 

X 

X 

X 

X 

X 

DERIVES 

or  UPDATES 

EIE  M^'T 

GROUP 

INPUT 

OUTPUT 

ENTITY 

SET 

USES 

nS"S  TO  DEPIVE 

X 

X 

X 

X 

X 

USES  TO  UPD»TE 

X 

X 

X 

X 

’'DRIVES 

Y 

X 

X 

X 

X 

DFR''VE3/DS‘’VG 

y 

X 

X 

X 

X 

U^DA  TF5 

X 

Y 

X 

X 

U’^DA  TES/USTNO 

X 

X 

X 

X 

T^ible  2.U.2 

Sf»rivation  Relationships  for 
nSEo,  npDATrS  anl  DERIVES  Statements 


r 
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EL’='TRNT 

GROUP 

INPQI 

RECE  IVES 

Not  AllOWPfl 

Not  Alloved 

Every  INPUT 
should  be 
RECEIVED  by 
at  least  one 
PROCESS 

GEWf PATES 

Not  A llowed 

Not  Allowed 

Not  Allowed 

USES 

SVPrv  ILF  KEN" 
shoulT  bo  usft'l 
by  a*  least 
one  PROCESS 

At  least  one 
ELEMENT  in 
the  GROUP  is 
used  by  the 
PROCESS 

At  least  one 
ELEMENT  in  the 
INPUT  is  used 
by  the  PROCESS 

DEPI VES 

Valvie  of  an 
ELEMENT  is 
derived  bv 
the  PROSESS 

Value  of  at 
least  one 
ELEMENT  in  the 
GROUP  is  de- 
rived by  the 

PR OCESS 

Not  Allowed 

UPDATES 

1)  Value  of  an 
ELEMENT  is 
upda^’od  by 

t ho  process 

2)  ELBKEN" 
shoul d be 

CON'^A  INFU 
in  at  least 
one  ENTITY 

1)  value  of  at 
least  one 
ELE.MEWT  in 
the  GPOUP  is 
updated  by 
PPOCESS 

2)  GROUP  should 
he  CONTAINED 

in  at  least 
one  ENTITY 

Not  Allowed 

Table  2.4.3 

Data  derivation  (PFOCESS) 

Seaantics 
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on'^p'iT 

ENTIIY 

CVT 

RECEIVES 

Not  Allowed 

Not  Allowed 

Not  Allowed 

GTVEPATFE 

Every  CHtput 
should  be 
GENERATED  by 
at  least  one 
PPOCE  SS 

Not  Allowed 

Not  Allowed 

USES 

Not  Allowed 

At  least  one 
ELEMENT  in 
the  ENTITY 
is  used  by 
the  PROCESS 

At  least  one 
ELEMEN'"  in  the 

SET  is  used  by 
PROCESS 

OEPI VFS 

Valuo  of  at 
leas'-  or.o 
ELEMENT  in 
gn-nnuT  is  de- 
rived by  the 
PROCESS 

At  least  one 
ELEMEN'"  in 
the  ENTITY 
is  derived 

At  least  one 
ELEMENT  in  the 

SET  is  derived 

UPDATE?  ‘lot  Value  of  at, 

least  one 
ELEMENT  in 
the  entity 
is  updated 
by  the 
PROCESS 


Value  of  at  least 
one  ELBHENr  in  the 
SS’’’  is  updated  by 
the  PROCESS 


Table  2.«.3 
(Continued) 
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A jET,  entity,  TEOnP  or  ELEMENT  nay  be  UPDATED  by  any  ntiaber  of 
PROCESSES.  An  optional  using  clause  nay  be  used  in  conlanction 
with  the  UPDATEn  statement  in  the  following  manner: 

nPDP"'SD  UY  PI  USING  E2; 

Where  E2  is  any  number  of  data  obiects  that  nay  be  USED  by  a 
PROCESS. 

An  OU'^Pt?'",  SET,  EN’’TTY,  GEOUP  or  ELEMENT  nay  he  DERIVED  by  any 
number  of  PROCESSES.  An  optional  USING  clause  nay  be  used  In 
coni  unction  with  the  DERIVED  statement  in  the  following  nanner: 

DERIVED  BY  PI  USING  E2; 

Where  E2  is  any  number  of  data  obiects  that  nay  be  USED  by  a 
PROCESS. 

A RELA'^TON  may  be  MAINTAINED  by  any  number  of  PROCESSES,  and  a 
PROCESS  may  KATNTATW  any  number  of  RELATIONS. 

A PPricESS  may  have  any  number  of  PRCCEDUBE  connent  entries 
soecified,  but  all  the  comment  entries  will  be  coabined  into  ona 
pnocEDUF’'  comment  entrv  when  presented  in  any  UFA  report. 

A SE*^  or  RELATION  may  have  any  number  of  DERIVATION  connent 
entries  specified,  but  all  these  connent  entries  will  be 
combined  into  one  DERIVATION  comment  entry  when  presented  in  any 
URA  report. 


When  a collection  of  data  (e.g.,  an  ENTITY  or  GROUP)  is  USED, 
this  implies  that  at  least  one  ELEMENT  within  the  collection 
(assunim  the  collection  is,  or  will  be,  broken  down  to  one 
ELEMEN*"  level)  is  USED. 

When  a collection  of  data  is  UPDA'^ED,  this  implies  that  at  least 
one  ELEMENT  within  the  collection  is  UPDATED. 


f 


[ 


wh »n  a collection  of  data  is  DERIVED,  this  implies  that  at  least 
one  *’LE'*ENT  within  '^^he  collection  is  DERIVED. 

Whenever  PPDCESS’=’S  or  PROCESSORS  access  data,  whether  deriving, 
updating  or  using  i*- , the  CI.ASSI’=’ICATION  of  the  data  and  the 
SFCUPITY-ACCrgs-RIGHTS  of  PROCESS  or  PROCESSOR  should  natch.  In 
order  to  match,  the  PROCESS  or  PROCESSOR  should  have 
S'“CUPITY-ACCESS- RIGHTS  at  a level  greater  than  or  egual  to  the 
CLASSTFTCA-"ION  of  the  data  obdect. 


2.4.4  Data  Derivation  Common  Eguivalents  and  Us^qe 

In  most  manual  documentation  methods,  the  information  related  to 
"data  derivation”  is  usually  implicitly  included  in  flow  charts. 
Plow  charts  usually  contain  more  than  lust  the  "data 
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ipri  va^-ion,  ” an'i  , t:onspquently , data  derivation  Bay  not  be 
clearly  presented. 

A PFOCESS  that  is  fJ'^TLT7Eri  represents  soBe  function  within  the 
svsteni  that  is  incorporated  by  two  or  more  hiqher  level 
PPOCESSE?.  For  example,  a validation  routine  sight  be  a PROCESS 
n"'iLI7ET)  by  soypral  other  PROCESSES  to  perform  their  defined 
functions. 

I 

The  ppocEO'iPE  comment  entry  within  the  PROCESS  description  may 
be  used  to  describe  the  algorithms  required  to  define  the 
ppocFSS.  Since  the  PROCEDURE  is  text,  decision  tables  lay  be 
incl nded . 

•"ho  DEPIVATION  comment  entry  within  the  SET  or  RELATION 
descrintions  mav  be  us«d  to  define  the  rules  to  derive  an 
occurrence  of  a RET.A""I0N  between  two  ENTITIES,  or  occurrences  of 
I a member  within  a S*’T. 


2.4.  h Pa^  Derivation  Outjjuts 

Th'^  PICTURE  report  (with  the  DATA  cption  in  effect)  can  be  used 
to  present  data  derivation  relationships  (OSES,  UPDATES,  and 
DERIVES)  among  S^TF,  IV'PUTS,  OUTPUTS,  ENTITIES,  GROUPS,  ELEKENTS 
an  1 processes  in  a graphical  format. 

The  extended  PTCTUPF  report  (with  the  DATA-FLOW  option  in 
effect)  can  be  used  to  present  the  all  data  derivation 
relationships  (USES,  nPDA'"FD,  DERIVED,  GENERATED,  and  RECEIVED) 
among  SETS,  INPO-’E,  OUtpu'^S,  ENTITIES,  GROUPS,  ELEMENTS, 
P'^OCESS^S,  and  INT^pfacES  in  a graphical  tree- structured  format 
looting  FORWARD  or  PACKWARP  in  the  tree. 

The  FRccESS-lNPUT/onTPUT  report  presents  most  of  the  inforaation 
as  described  above  for  PROCESS  naoes  only,  but  in  an  alternate 
format.  This  report  will  also  present  any  DESCRIPTION  and 
PROCEDURT  comment  entries  related  to  the  PROCESS  naaes. 

■"he  data  PROCESS  report  presents  the  interaction  of  data  obdects 
wi*-h  PPOCTSspc^  a matrix  format.  This  has  the  advantage  of 
presenting  the  dependencies  of  data  by  PROCESSES  for  the  entire 
system.  a second  matrix  is  also  produced  to  present  the  degree 
in  which  PROCESSES  interact  with  each  other;  i.e.,  to  produce 
data  that  oth«r  PROCESSES  use  or  to  require  data  that  other 
PROCESSES  produce. 


2.4.A  Data,  Derivatio r Completeness  Checks 

1)  Ev^rv  PROCESS  should  acquire  some  data  either  by  USING  or 
FPT  ATTNG. 

2)  Every  PROCESS  should  produce  data  by  DERIVING  or  by 
UPDATING. 
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■»)  Every  SET  should  be  USED  or  UPDATED  by  some  PROCESS, 

tt)  Every  ENTITY  should  be  USED  or  UPDATED  by  soiie  PROCESS. 

S)  Every  ELEJ^ENT  in  an  *’NTITY  should  serve  at  least  one 
pur rose: 

- IDENTIFIER  of  the  '='NTTTY 

- ueeD  by  some  PROCESS,  or 

- UPDATED  by  some  PPOCESS. 

P')  Procossinq  statenent s in  which  RPOUFS  appear  should  apply 
to  at  least  one  elekent  in  the  GROUP. 

7)  Every  Bl.BrEN''’  CONTAINED  in  an  INPUT  should  be  USED  in  soee 
way. 

S)  Every  ELEMENT  CONTAINED  in  an  ENTITY  should  serve  a 
purpose . 

S)  '“‘very  ELEM'^NT  cnN'''AlNED  in  an  OUTPUT  should  be  DERIVED  by 
some  PPOCESS. 

10)  An  FLEMEN'^  CONTAINED  in  an  INPUT  should  not  be  DERIVED. 

1t)  An  FLEMEN""  should  only  be  DERIVED  once. 

12)  Every  ELEMENT  USED  by  a PROCESS  should  he  available  froi 
sum e source  : 

i)  INPUT 

ii)  DESIVED  bv  some  other  PROCESS 

iii)  from  an  E*?TTTY. 


? • *5  Sysy stew  Size 

Th“  complete  specif ica'' ion  of  requirements  for  the  target  system 
requires  statement  of  parameters  that  specify  the  volume  of  work 
that  the  system  will  have  to  do  and  the  amount  of  resources  that 
it  will  require.  Two  types  of  data  should  be  qiven. 

Size  - number  of  members  in  each  SET,  number  of  repetitions 
in  each  repeating  GROUP  in  an  INPUT,  etc. 

Volume  - number  of  instances  of  INPUTS  and  OUTPUTS,  number  of 
times  PFOCE’^SES  will  be  executed,  etc,  in  a given 
period  of  time. 

In  URL,  the  parameters  which  characterize  size  are  called 
SYSTEN-PA'>AmET?RS ; they  can  be  name  symbolically  and  their 
values  expressed  numerically. 

T.S.I  System  fiSS  Ob  Meets 

SYS'rEH-PAPA'lB'''E'»  - an  oblect  which  affects  the  size  of  the 

system.  It  is  given  a name  and  may  be 
given  a numeric  value. 

INTEVAl  - an  object  representing  some  time  period 

such  as  a week,  year,  millisecond, 
planning  period,  etc. 
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2. ‘^.2  5iZ®  Pp  lationsh  ips 

VALUFP 

A 3Y  ?T’!f’-PAFA'^F'^EP  nay  have  a VALUE,  or  a range  of  VALUES.  An 
ELFMF.N'"  nay  also  have  a VALUE  or  range  of  VALUES  associated  with 
it . 

CAPniNALITY 

an  ynTI'^Y,  or  SET,  or  PELATION  nay  have  a CAPDINALITY. 

CONNECT-' VT'"Y 

A PELATION  nay  havp  a CONNECTIVITY  defined  by  specifying  two 
SYSTEW-PAFAHETEPS. 


HAPPENS 

An  INFU"-,  OUTnuT,  EVEN'’’,  or  PPOCESS  may  HAPPEN  a 
SYSTEM-PAFAM’^TEP  (number)  of  times  in  a given  INTERVAL. 


CONSISTS 


A may  CONSTS'^  of  a SYSTEK-P AF AKE'^'ER  (number)  of  ENTITIES, 

INPUTS,  or  OUTPUT*^.  An  INPUT,  OUTPUT,  ENTITY,  or  GROUP  may 
CONSIST-  of  a SYSTEr.-PAPAMFTFP  (number)  of  GROUPS  and/or 
ELEHFN*:S.  An  TNT’=‘PVAL  may  CONSIST  of  a SYSTEM-PARAMETER 
(number)  of  INTFOVALS. 


2.5.3  System  Size  Syntax  ^d  Semantics 

"•he  cbiects  and  rela  ionships  involved  in  describing  system  siza 
are  shown  oictorially  in  Figures  2.5.1,  2.5,2  and  2.5.3,  and  in 
tabular  form  in  Table  2.5.1. 

•^he  VALUE  or  VALUES  associated  with  a SYSTEM-PARAMETER  or 
ELEMENT  must  he  numeric  and  once  a VALUE  (or  VALUES)  has  been 
assigned,  no  other  VALUES  raav  be  given  to  it. 

CAPDINAIITY  specifies  a number  of  occurrences.  With  respect  to 
SETS,  it  specifies  ►be  number  o^  ENTITIES,  INPUTS,  or  OUTPUTS 
► hat  may  hf»  COV^AINEP  in  the  SET  at  any  one  time.  With  respect 
to  ENTITIES,  it  specifies  the  number  of  occurrences  of  a 
particular  ENTITY  in  the  system  at  any  one  time.  With  respect 
to  *’ El  AT  IONS,  it  specifies  the  number  of  connections  made 
between  ENTITIES  via  a particular  RELATION.  A particular 
ENTITY,  SEf,  or  RELATION  may  have  only  one  CARDINALITY. 
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CONN Fr"’? VITY  sp<?cifi<»s  the  structure  and  magnitude  of  a 
PPLA^roK.  A particular  ’’FLATION  may  have  only  one  CONNECTIVITY. 

The  HAPFENS  s^a^ement  specifies  the  number  of  occurrences  of  an 
CMTPfJT,  FVPNP,  or  PROCESS  in  a given  time  interval.  A 
narticular  Input,  outpu’"^  event,  or  PROCESS  may  have  only  one 
HAPPENS  Statement. 

•"he  CONFIS"’"  statement  used  in  coniunction  with  a SySTEB- 
PAPABE""??  specifies  that  for  each  occurrence  of  a given  SET, 
e.g.,  the  data  CONTATNFP  in  it  occurs  the  designated  number  of 
♦•im“s.  Any  particular  data  object  may  only  consist  of  another 
data  object,  one  given  SYSTE B-PAPAHETEH  number  of  occurrences. 


2.^.  n System  Size  Common  Egu ivalent  and  Usag e 

In  the  usual  methods  of  system  documentation,  description  of 
size  and  volume  aspects  are  incorporated  into  the  descriptions 
of  o*-her  object’s  as  rumerical  values. 

(One  important  feature  of  PPL  in  specifying  size  is  that  it 
permi«-s,  and  in  fact  encourages,  all  such  specifications  to  be 
symbolic,  i.e.,  each  parameter  is  given  a name.  Consequently, 
all  situations  in  which  a given  parameter  appears  can  be 
colTec+ed  and  examined.  Numerical  values  need  only  be  assigned 
at  the  time  a*"  which  they  are  definitely  needed.  For  example, 
when  a sys^-em  is  ini^-ialiy  being  described,  it  may  only  be  known 
♦•hat  the  group  "job-data"  CONSISTS  of  the  element  "occupation." 
Tt  may  not  he  known  or  not  specified  until  much  later  that 
job- data  CONSISTS  of  3 or  6 occurrences  of  "occupation." 
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HP.i8C/:'ni,TTC3/nPL  user's  mamhal 
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Figure  2.5.1  Pelation  of  Ob-jects  to  a SYSTEM  PARAME'^ER 
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INTERVAL 

S YS”FM 
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to  Size  and  Volume 
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2.  P.6  Syst-^m  Pu  puts 


■"o  obtain  informa’'ion  specifically  about  one  or  more 
«:Y5;TE’»-PARA1FT"'Rf5,  the  FOPbATTEb  PROBLEM  STATEMENT  may  be 
aeneratei.  Sine®  very  few  of  the  statements  involving 
c;Y<57*>w-.p p'pf p s hfive  complementary  statements,  much  of  the 
information  presented  in  the  POPKATTED  PROBLEM  STATEMENT  will  be 
in  comment  format. 


System  Bize  CSJSilSlSDSSS  Checks 
"he  fell  owing  checks  can  be  made; 


1) 

"very 

?.) 

Fvery 

3) 

Every 

U) 

Every 

'■'» 

Fverv 

6) 

Every 

Every 

3) 

Ivery 

2.6 

System' 

should  have  a HAPEENS/TIMES  statement, 
should  have  a HAPPENS/TIMES  statement. 
3uld  have  a CAPPTNALITY  statement, 
should  have  a CAPDINALITY  statement. 

• should  have  a HAPPENS/TIMES  statement, 
jhonld  have  a HAFFENS/T IKES  statement. 


"he  description  of  the  contents  of  INPUTS,  OUTPUTS,  ENTI'^IES, 
opours  and  structures  of  PROCESSES,  and  the  relationships  among 
♦•hese  obiects  nroduced  up  to  this  point,  gives  a "static" 
description  of  he  system,  "his  does  not  in  itself  state  the 
reou  itemen’T.  for  the  dynamic  behavior  of  a system.  To  do  this, 
one  must  describe  ♦^hose  innu't's,  conditions  and  events  which  may 
influence  wha*-  processing  is  performed,  or  the  order  in  which  it 
is  performed. 


2.6. 1 21  stem-  .2lLk!Li22  Object  s 

rcNPIT’'ov  - a statement  which  can  be  in  one  of  two  states, 

"PUF  or  FALPE  (YES  or  NO,  etc.)  . The  statement 
is  given  a unioue  name. 

rvvv'T  _ obiert  used  to  describe  a happening, 

externa]  or  internal  to  the  system,  or  an 
occurrence  which  causes  something  else  in  the 
system  to  happen  . 

2.6.2  System-nyn  amirs  Pelationsh  jps 


CAME  ’^S/C  A'JSEP 

An  rV'N"  or  INPUT,  or  a CONDITION  PECOMINO  TRUE  or  FALSE,  CAUSES 
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FVF»r.  An  5VEN"'  is  CAUSED  bv  an  EVENT,  an  INPUT,  or  a 
coNPiTTCN  REcnrT‘»<'.  "rur  or  ''alsf. 


T'ICF  PEIOV-rA  US'S/Of  T NrPPTIO  N 

IMCEPTirN  of  a CAP'^F.E  an  EVENT,  or  an  ^VENT  occurs  ON 

■^NCFPTICN  of  a PPOCPSE. 


■^'>'"EFFUP"'9/INT'pPPnP’”’='E 

A PPOCESS,  or  INPUT,  or  a CCNTITION  BECOMING  TRUE  or 

FAIT'',  : NT’=:^®’IPTE  a PPOCFES.  A PPOCESS  is  INTERRUPTED  by  a 
PPOCEFS,  EVSN^  or  INt-UT,  or  by  a CCNDITICN  BECOMING  TRUE  or 
'’ALEF. 


MA  <f '^•c/MA  PE 

An  ’’•''FM",  ’■NP’r  or  opoc^FE  MAKES  a CONDITION  "^PUE  or  FALSE.  A 
CONPI"TON  is  '•AP'’  "r-UE  or  FALSE  by  an  EVEN"^,  INPUT  or  PROCESS. 


'^'•’^‘•INA"-ES/TFPri  NA'-EP 

A OPOCESE,  EV'^'"^  or  ’’NPUT,  or  a CONDITION  BECOMING  TRUE  or 
FALSE,  'TERMINATES  a PPOCFSS.  A PFCCESS  is  TERMINATED  by  a 
DpnC'='EE,  EV^'N'T  or  I’’ PUT,  or  by  a CONDITION  BECOMING  TRUE  or 

PALET . 


-•ppv  inatton-caue  FE/ON  ieomin  ation 

TNATIO'I  o*  a PfOrZES  CAUSES  an  EVENT,  or  an  EVENT  occurs  ON 
IFATION  of  a PRPCESE. 


"■rj<5f;rT5C  /""PIG  G'T'a  ?p 

a ppnc-fS,  fv’^Nt  or  INorj-r^  ^ CONDITION  is  BFCOMING  TRUE  or 
FALSE,  TFIEEFR3  a PPOCESS.  \ PROCESS  is  TRIGGERED  by  a PROCESS, 
ftfet  or  TNon”,  or  by  a CONDITION'S  BECOMING  TRUE  or  FALSE. 


WUTLE 

A CONDT-TTON  may  b«  T^UE  WHILE  or  FALSE  WHILE  some  criteria  hold. 


?.S.  i Sys'-om-  uynamir  s Syr. fa x and  Semantics 

'The  obiecfs  and  relationships  involved  in  describing  system 
dynanics  at'’  shown  nictorially  in  Fiaure  2.6.1  and  in  tabular 
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form  in  Table  2.6.1. 


INCEPTION  or  TEPMINATION  of  a PPOCESS  may  CAUSE  any  number  of 
T'VENl!;.  Similarly,  an  EVEPT  may  occur  ON  INCEPTION  or  DN 
TEyf*  INA'^IOM  of  any  number  of  PFOCESSES.  The  INCEPTION  of  a 
OPOCESS  is  its  heoinninq,  TEPMINATTON  is  the  completion  of  the 
PPOC^'SS. 

Anv  rumber  of  EV’='N'^S  , INPUTS,  and/or  CONDITIONS  may  CAUSE  and 
EVENT.  Uowever,  a separate  statement  is  required  for  each 
CONPT'^ION  involved.  Similarly,  any  number  of  EVENTS  may  be 
CAUSED  by  a aiven  collection  of  EVENTS,  INPUTS,  and/or 
CONDITIONS. 

Any  number  of  EVENT'-,  INPUTS  and/or  PROCESSES  may  HAKE  a 
COMni-lOH  -"PUE  or  FALSE.  Any  number  of  CONDITIONS  may  be  MADE 
•"Ptir  or  FALSE  by  a qiven  collection  cf  EVENTS,  INPUTS  an  i/or 
'''►OOESS^S.  Only  one  of  the  values,  TRUE  and  FALSE,  may  be  used 
in  a qiven  MAKES  of  MADE  statement.  The  tern  MAKES  implies 
setting  th“  value  or  a CONDITION. 

Anv  number  of  PFOCESSES,  FVEN'^S,  INPU-^S  and/or  CONDITIONS  may 
'"’’lOGFP,  INTEPPUPT  or  TEPMINATE  a qiven  PROCESS.  Any  number  of 
PROCESSES  mav  be  TFTO,GEPED,  TNTERPtPTED  or  TERMINATED  by  a given 
collection  of  '’POCESSES,  EVENTS,  INPUTS  and/or  CONDITIONS.  To 
•'PTOC^-^  a opnc^SS  is  to  initiate  it.  A PROCESS  is  INTERRUPTED 
if  it  is  eligible  to  be  resumed  later,  while  it  is  TERMINATED  if 
it  is  ended  (whether  complete  of  net)  and  is  not  to  be  resumed. 

A cdn^i’T'^ov  mav  only  have  one  WHILE  statement,  which  is 
exoressed  as  a comment  entry.  Should  more  than  one  be  specified 
tor  a qiv«n  CONDI'^ION,  the  comment  entries  will  be  combined  (the 
second  added  to  the  end  of  the  first  and  so  on). 
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CAUSES 

Table 
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pnoT-  y gccp  FF0UIREBFN7S  LANGUAIS  MANUAL 


PO/*:UL'riCS/l’PL  USER'S  MANMAL 


’01 


~0\IT>T7iov 

INPUT 

PROC  E‘5'' 

{TPUF) 

MAf*'S  — f’^ALSE] 

TPIGGEPEP  WHFN 

{TRUE) 

— BECCIFS  fPALSEI 

TRIGGEPPD  BY 

TFRKTNA'T'FD  BY 

INTERRUPTED  BY 

rEP“rNA"‘'='n  whfn 

fTPUEl 

— BECOEFS  fFALSEI 

INT^'PEUrTED  MHF'I 

frPtlE} 

— BFCOrrS  {PALBF} 

'•VEN  T 

!«AKPB  — {FALSE} 

'' A USED  WHEN  — 

{TPUF} 

3F''0*!FS  {FALSE} 

CAUSED  BY 

C'^'jn  ITTO  N 

wh:l’='  * 

{TRUE} 

EADE  {FALSF}  BY 

{TFUE> 

?!AFRS  --  {FAL.S’^} 

* comirr'n'- 

‘'ntrv  onlv 

Table  2.6.1 

(Contin  ued) 
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2.^.4  System- Dyn awics  Comaon  Equivalents  and  Usage 

As  is  tho  case  with  system  si/e,  description  of  system  dynamics 
aspects  ar«>  often  not  stated  explicitly  but  are  incorporated 
into  the  descriotions  of  ctner  objects.  In  some  cases,  this 
♦■yoo  of  information  is  presented  by  decision  tables  or  by 
decision  ►•locVr.  in  flow  charting  methods. 

•'ince  decision  tables  present  a plan  of  "action"  based  on 
conditions  and  events,  they  may  be  given  in  the  PfiOCEDOEE 
statement-  for  the  appropriate  PPCCESS,  if  desired. 

A list  of  ’='VEN"''5  '"PTOGEPINC  a FPOCEPS  implies  that  each  one  of 
the  EVENTS  TFiagEFS  the  PF0CFS5.  Since  an  EVENT  occurs  at  an 
ins»-ant  in  time,  the  user  should  net  need  to  say  that  a 
combination  of  ’'VENTS  TPIGGEP3  a PPOCESS,  since  this  would 
roguite  that  all  ’■he  EV’^NTS  occur  simultaneously. 

’'v‘»n  ’■hough  there  is  no  way  to  state  explicitly  that  a 
combination  of  CONDITIONS  "’RIGGFFS  a PPOCESS,  this  may  easily  be 
handled  by  defining  a new  CONDITION  to  represent  the 
comb  ina’- ion . ’'nr  example,  i’"  F^PCISS  Pi  is  TPIGGEFED  when 
condition  cl  is  TP’”'  an-^  CONDIlTON  C2  is  FALSE,  the  user  may 
wri’^  e : 

CONDT’’’ION  Cl; 

"PUS  NHILE; 

d AND  NOT  C 2 ; 

PF  OC^‘5  S . 

TPTGG’'PED  VHFN  Cl  RECOMES  TPUP; 

Any  EVEN”"  or  CONDI'’'Ton  that  affects  the  system’s  operation, 
should  be  defined. 


2.b.S  S vs^m^biP  amigs  Output  s 

"ha  "OPMA'’’T''D  ^POPLEK  S’’'ATEMENT  may  be  generated  to  obtain 
inforira’-ion  about  one  or  more  CCNPITIONS  or  EVENTS. 

"he  PFOCE’^r  CHAIN  report  will  show  structures  of  EVENTS  and 
PPOCi'ESES  cornec’^ed  by  TFIGr,’’’PS  and  ’’'PIGGEPED  BY  statements. 


System- '’vn a mic s Comple teness  Check s 

1)  Fvery  EV’'N7  should  be  associated  with  at  least  one 
CONDITION  or  PFOCFSS. 

2)  Every  TONottION  should  be  associated  with  at  least  one 
FVENT  or  PPOCFSS  . 

■»)  ’"very  CONDITION  should  have  a TRUE  WHILE  or  a FALSE  WHILE 
St  a t em  e n t . 
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-^yst  pm  A rchS  tec<~  urp 

The  system  architecture  description  deals  with  the  physical 
asoects  of  an  information  processinq  system. 

2.7.1  Sv s^m  Architecture  Objects 

P»?OCt'ssOP  - an  obiect  that  can  "perform"  a PROCESS. 

t?p<?nriFCF  - something  that  the  physical  elements  in  the 

target  system  consume  in  order  to  carry  out 
information  processing  functions. 

HNIT  - an  object  used  to  measure  RESOURCES. 

AOE-  used  to  define  a measure  of  the  RESOURCE 
PAPAME'^FP  - tisaqe  for  a PRCCESS. 


"'.7.2  fvstem  Architecture  ^’elat  ionships 

CONSnitFc/cniSUFED  ny  - A F'^FOURCE  may  he  CONSUKED  BY  a 

PROCESSOR,  and  a PROCESSOR  Pay 
CCNSrPE  an  amount  of  PESOOPCE  PER 
PESOOPCE-US  AGE- PAPA  METER. 

p^nFOPrf /PEP  FOt-v  pr  py  - A ^’ROCESSOF  may  PEPFOPH  a PROCESS, 

and  a PROCESS  may  be  PERFORMED  BY  a 
PROCESSOR. 


>'=’ASI'^ES/M’=’ASU-En  IN  - A UNIT  may  MEASURE  a RESOURCE,  and 

a RESOURCE  may  be  MEASURED  IN  a 
UNIT. 

F^30UFCF-USAG=/P''F"''^FCE-  A PROCESS  may  have  a RESOURCE- 

'TSAGE-PARATE'"^?- VALUE  - US AGE-P ABAMETER-V ALU S associated 

with  a RESOtlPCE-nSAGE-PAPAHETEP. 


C."*.  3 System  Arc  hi  tect^ire  S^n^x  and  Semantics 

""he  objects  an’  relationships  involved  in  describing  system 
architecture  ate  shown  in  "'able  2.7.1. 

A PPOOESS  may  have  an  arbitrary  number  of  RESOURCE-O S AGE- 
PAPA"ETEF  and  trsoMPCE-US AGE-PARAMETEP-VALUE  pairs.  (But  there 
can  only  be  at  most  one  such  pair  for  a particular 
PESOUPCE-USAGE-'>A?A*'FTEF.)  This  pair  is  used  to  describe  the 
expected  resource  consumption  by  the  execution  of  the  PROCESS  in 
a pooc^SSOP  independent  manner.  The  CONSUMES  statement  in  the 
P'»OCESSr'»  section  specifies  the  name  and  amount  of  RESOURCES 
’■hat  are  consumed  per  PESOUPCE-US AGE-PAR AMSTEP  of  the  PROCESS  it 
performs,  ""his  measure  is  translated  to  a resource  consumption 
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valup  bv  multiplyinq  th«  PESOURCE-USAGE-PARAMETER- VALUE  with  the 
r«»so«tce-cons'iiiption-value  for  the  RESOUPCS-US AGE-PARAMETER  in 
♦■he  CCNSni’^?  statement  of  the  PROCESSOR.  For  example,  suopose 
that  there  is  a dpOCFSS  and  a PROCESSOR  ••PRI,"  and  that 

the  oESOUPCP  in  question  is  "CPU-TIME"  (measured  in  UNIT  of 
"MTCPC-'^ECONn^^")  , as  in  Figure  2.7.1. 


RESOURCE- 

USAGE- 


5ISOUPCE 

UNIT  PARAMETER 

PROCESS 

PROC VSSC  R 

StlUPAPTS  CONSUMES 
r> A P'^’  OF 

CONSUMES 

PEP 

PERFORMS 

PFSCUPCF 

CONFPMED 

BY 

MEASUPEC 

IN 

UNT"" 

MEASUPFS 

PESO  UPCE 

FTC  V 

PAPAMETFP 

RESOUFCE- 
USAGE- 
PARAMETEB- 
VALUE  FOR 

pPQp 

PERFOPMFn 

PE  SOURCE- 

US  AGE 


■^able  2.7.1 

System  Architecture  Relationships 


Pp  OCSF  S ?1  ; 

FESOURCE-US  AGF:  10C  FOP  NC-CF- STATEMENT; 

PROCESS  P?  ; 

PFFOnPCE-'JS  AGE;  2Cr  FO?  NC-OF-STATEKENT 

PRCCESFO?  PRI; 

PERPOPM  S PI  ; 

CO‘’S'riFS  CPU-TIMF  AT  PAtE  OF  20  PER  NO-OF- 
STA"’FM’=''ITS; 


Figure  2.7.1 

Fxample  of  URL  statements  for 
PROCESSOR  an-i  its  FFSOUFCE-usaqe. 


Here  *ifT0-OP-S-»’'Fr»FNT"  is  a RHSOORCF-USAGE-PAP  AMETSR . The 
PROCESS  called  ?1  has  a value  of  100  for  this  parameter.  One 
nossihl®  interpretation  of  this  statement  is  that  the  relative 
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'’ifficull’y  or  complexity  of  the  PPOCZSS  is  such  that  it  would 
♦■ake  '•s^-atoraents”  on  a hypothetical  processor.  Other 

npor:  ^,SSes  may  ba  qiven  values  for  the  sane  PESOUPCE-USAGS- 
’’APAMETEP.  For  example,  PROCESS  P2,  which  is  considered  twice 
as  difficult  or  complex,  is  qiven  the  value  200  for  this 
FESnriFCP-nS  AGE-PARAFF^EP.  Mote  that  the  PESO  UPCE- US  AGE- 
PAPAFFT’^p  and  its  value  are  meant  to  be  FPOCESSOF  independent. 
They  are  used  to  record  estimation  of  PESOURCF-OSAGE  independent 
of  what  PROCESSOR  performs  the  particular  PROCESS. 

In  the  PPOCESSOR  section,  the  CONSUMES  statement  is  used  to 
record  the  resource- corsumpt ion-value  for  a RESOURCE-USAGE- 
P PAFFTFP.  In  the  example  of  Figure  2.7.1,  20  is  the 
reso urce-con sumotion-value  of  the  PROCESSOR  "PRl"  for  the 
P^SO  rjpcF-nSAGE-P  ARAMFTEP  "NO-OF-ST  ATEMEN  T . "MICRO- SECO  NDS"  is 
the  name  of  the  umt"  that  is  used  to  measure  the  RESOURCE  called 

Mf^nn-IT  V P,  H 

This  s*-atemen*’  may  he  interpreted  as  sayinq  that  the  PROCESSOR 
iiopi  n yiii  consume  20  microseconds  of  CPU  time  per  "number  of 
statements”  (qiven  in  the  PPOCESS  description)  whenever  it 
nerforms  a ppocEFF.  In  this  example,  2,000  (100  x 20) 
microseconds  of  CPU  time  is  consumed  by  PROCESSOR  "PPl"  whenever 
it  nerforms  PROCESS  "?1,"  and  h,00C  (200  x 20)  microseconds  for 
1102 . " 

is  possible  to  associate  more  than  one  RFSOURCE-US  AGB- 
PA^AMF^FF  (and  its  value)  for  a PROCESS.  It  may  be  used  to 
allow  for  ♦•he  possibility  of  employing  two  completely  different 
tVDOE  of  nroc^ssors  (like  a computer  and  a person)  to  perform 
the  PROCFSS.  In  this  wav,  the  decision  as  to  what  "POCESSOP  to 
use  for  a particular  PROCESS  may  be  delayed  as  necessary  and 
chanqina  the  PROCESSOR  for  a PROCFSS  once  it  is  decided  is 
easier.  ‘laving  more  than  one  pair  of  RFSOURCE-US  AGE-PAR  AMETERs 
an  •!  its  value  may  also  he  used  to  describe  resource  consumption 
independently  for  more  than  one  resource.  Only  the  resource 
consump*- ion  value,  which  has  the  same  PESOUPCE-US  AGE-PAR  AHETER 
in  both  PROCESS  and  PROCESSOR  sections,  is  taken  as  contributing 
to  the  actual  resource  consumption.  If  there  are  multiple 
instances  such  PARAMETERS,  the  net  consumption  for  a resource 
is  ♦■he  sum  of  all  ♦■he  consumption  values. 

'♦’he  n-pFOP''s/ps:PFor'' FD  PY  statement  is  to  record  the 
relationship  ho»-w<’pn  a PROCESS  and  the  PROCESSOR  that  performs 
(i.e.,  carries  O'l^,  does,  etc.)  the  PROCESS.  A PROCESSOR  can 
perform  more  than  one  PPOCFSSes,  but  a PROCESS  can  be  performed 
bv  only  one  PROCESSOR. 

-"h®  MFASUPES/M’^’A'JrRFr  IV  statement  is  to  define  relationships 
between  a MVI'"  and  a ’’ESOURCE.  A UNIT  may  measure  more  than  one 
ncqpqyc'’,  bu^-  a RESOURCE  can  be  measured  only  in  one  UNIT.  The 
UVTf  name  ♦•ha*  appears  after  the  resoiirce-consum ption-va lue  in 
the  CCVSnypf;  s*a*emert  of  the  PROCESSOR  section  is  optional,  but 
if  it  is3  given  it  must  he  th®  correct  UNIT  name  for  that 
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^’’Son'scF . 


?.7.u  «^vst»ni  Arr hi^QS-tUIi'  Completeness  Checks 

•^he  ccnoleteness  checks  that  can  be  made  for  SAF  objects  are: 

1)  Fvery  ?POrFS3  should  be  PEPFOFMED  BY  a PPOCESSOR  and  every 
IPOrE'^‘‘C'’  should  PERFORM  at  least  one  PROCESS.  At  each 
su*'division  of  PROCESF  and  PROCESSOR  SU  BPARTS/P  ART  OF 
structure,  the  PF^FOPMS /^ERPCPMED  PY  relationships  of  the 
subparts  should  be  consistent  with  the  relationships  of  the 
parent  obiec*s. 

2)  If  a PPOCrsso^  "IFFCSKS  a FFOCESS,  at  least  one  common 
prsouPCE-ns  Aor-PAnAFFTEP  must  h€  defined  for  the  PROCESSOR 
(via  ''ONSUr^’f  statement),  and  for  the  PROCESS  (via 
FFFCUPCE-'ts  AOv  statement)  . 

1)  If  a SY  S'^F''-PAF  AMFTFF  is  used  for  PESOURCE-USAGS-PARAMETEF- 
VALUE  or  in  the  CONSUMES  statement  of  the  PPOCESSOR 
section,  it  must  have  ^ sinqle  numerical  value. 

4)  Fvery  UMI''  should  MFASUFS  at  least  one  FESOURCE,  and  every 
nFSnn-?c'’  should  he  measured  in  a UNIT,  and  CONSUMED  BY  at 
least  on^  PPOCFSSOP. 


2 . B P lopert ies 

' ""he  facilities  described  in  this  section  are  available  to  aid 

all  asoects  of  documentation,  communication  and  analysis.  Thesa 
facilities  also  provide  onen-ended  classification  systems  since 
th®se  "oualifiors"  may  be  added  at  any  time  and  used  for 
f retrieval  of  narts  of  the  problem  statement.  They  can  be  used 

I tj  describe  anv  of  the  objects  whether  in  the  orqaniiati on , the 

tarqet  svs'-em  or  in  the  project.  They  may  be  used  in  cases 
wh«»re  the  analyst  wishes  to  include  some  information  in  the 
documentation  wher^'  no  formal  syntax  is  available. 


2.B.1  ’^ropert  jos  Ob  j ect  s 

is  used  to  define  an  alternative  name  (alias) 
for  a qiven  named  object  in  the  URL  description 
of  the  system.  i 

ar  object  associated  to  one  or  more  names  for  | 

th*  purpose  of  selection  and  analysis.  I 

an  object  which  represents  text  relevant  to  one  j 

or  mere  other  objects.  i 

j 
I 
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ATTRIBUTE  and  ATTETRUTE-VALUE  - oh-Jects  used  to  describe 

characteristics  of  objects  not  otherwise 
allowed  in  the  language. 

SOURCE  - an  obiect  which  is  to  be  referenced  for  sore 

information  about  an  object.  Examples  of 
SOUFCES  are  interview-reports,  conpany 
orocedure  manuals,  documents,  etc. 

ci?ct'?iTY  - an  object  which  identifies  what  points  of  the 

nroblera  statement  may  be  reviewed  by  what 
1 nd i viduals . 


'"RAC^-K'=-Y  - 


an  ohipct  which  is  used  to  correlate  objects 
which  exist  in  different  data-bases. 


2.R.2  Prop'^r t ies  Pelatjonshi  ps 

PE'JC  HTP^TON 

»nv  ohiect  defined  in  the  problem  statement  may  have  a 
DESCPIP'''Io'i,  which  consists  of  one  or  more  lines  of  narrative 
toxt . A PESCPIPTION  is  not  a URL  object  and  does  not  have  a URL 
name . 


SYN'^NYK 

Anv  type  of  ohiect  may  have  SYNONYMS  and  a SYNONYM  may  be 
UESIUNAtEP  for  a given  object. 


ASSET 

Anv  object  which  has  a relationship  with  another  object  may  have 
an  ASSfOT  statement.  An  ASS''?'''  statement  asserts  that  one 
object  must  have  a particular  ATTRIBUTE  and  ATTR IBUTF-VA  LUE  when 
related  to  another  object. 


a -TF  IPtfES 

Any  object  nav  have  ,»"”^PTPlfTES  with  corresponding 
A 7TR  IPP^F- V*  T . 

KEYWOFDS/APPLIES 

Any  object  may  hav“  kfyworps  associated  with  it  and  a KETHORD 
mav  AFPIY  to  anv  type  of  object. 
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fFMC/At'DI.I'IS 


Anv  obipct  B-iy  havp  a S?F-W2f!0  and  a FFWO  may  APPLY  to  any 
oblect . 


SoriRCF/?  PPLT 

Any  obiect  may  have  a SOtJPCS,  and  a SonPCE  may  APPLY  to  any 
obiect . 


SECUPITY/APT^lTE? 

Any  obiect  mav  have  a SSCnpiTY,  and  a SECPRITY  may  APPLY  to  any 
obiec*". 


"'PACE-KFY/APPLr''S 

Anv  obiect  may  have  a TPACF-KFY,  and  a TPACE-FBY  may  APPLY  to 
any  obiect. 


P.P.’  Proper  and  Semantics 

"h"  obiect'-.  and  rela*- ionships  involved  in  describing  properties 
are  shown  oic^orlally  in  Figure  2.6.1  and  in  tabular  form  in 
-able  2.6.1. 

A oiven  obiec’-  may  have  only  one  DFSCBTPITON.  If  more  than  one 
PFSCPIP-TO'i  is  specified,  ♦^hey  will  he  combined  (concatenated  to 
the  end  of  the  or^viouslv  specified  DESCRIPTION).  Nhen  entering 
a 0FSCPIP-’’0v  into  the  data-base  it  is  important  to  note  that 
♦ h™  text  must  s<-art  on  the  line  following  the  word  DESCRIPTION. 

A giver  obiect  may  hav®  any  number  of  SYNONYMS,  but  a given 
®yNONYH  mav  belong  to  only  one  obiect.  SYNONYMS  may  be  used 
anywhere  in  a Problem  Statement  that  the  basic  name  may  be  used. 
A SYNCKY"  must  be  a nPL  name. 

A given  obiect  may  hav®  any  number  of  KFYWORDS  associated  with 
it.  KEYWORD*-,  however,  may  not  have  KEYWORDS.  A KEYWORD  may 
APPLY  to  any  number  of  obiect  names. 

A given  obiect  mav  hav®  anv  number  of  ATTPIBDTES,  but  for  a 
given  A'^'^RIR  , may  only  have  one  ATTRI EUTE-VALOE.  ATTRIBUTES 
mav  not  have  A'’'TPIPgTFS . An  atTPIBU^'E  can  have  any  number  of 
value*. 
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^ Ti  v€n  oh^f»ct  m^v  have-  any  nuicber  of  ASSEPT  statenents  which 
relate  that  obiect  o other  obiects  having  oarticular  ATTRIBUTES 
an.1  AT'^'F -^BiITE- VA  LUFS  . 

A given  o'^tec'’  may  have  arv  number  of  SFE-HPMO  statements.  A 

however,  may  not  have  any  SEF-KE^O  statements.  A lEHO  may 
'“’'PLY  to  any  number  of  namel  ob-jects. 

An  obleC-  may  have  any  number  of  snUECES  and  any  SOUPCE  may 
APPLY  to  anv  ntimber  of  oblects. 

An  obiert  may  have  any  number  of  SECURITIES  and  any  SECURITY  may 
>PPI,Y  to  any  number  of  obiects. 

»n  obier*-  may  have  any  number  of  TEACE-KEYS  and  any  TRACS-KEY 
mav  APPLY  any  number  cf  obiects. 
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A.  "'"M  BUTE 

TC 

SOURCE 

IS 

SECURITY 

IS 

* o'-h€r  '^FYWf'PD,  '■SMO,  AT-'^PIRUTE,  A TTF  I BUTS- V ALU  E , SOIIPCE 

or  SfCURITY 

■"able  2.8.1 
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2.^3.  4 n roppr  » jps  Common  Fqui  val^nts  an»1  U sag e 

"h®  DFSCRJOTTON  ansoria^ed  with  a given  object  is  analogous  to 
any  text  inscription  presented  in  most  documentation  aethods. 

T*-  may  con'^^a  in  any  tables,  charts  or  figures  which  can  be 
displayed  by  the  output  device. 

A 'in  L SYNONYM  has  ♦'he  same  meaning  as  commonly  used.  Its  two 
major  uses  in  imt  are; 

1)  So  reduce  the  number  of  characters  used  in  specifying  the 
problem  .-*-a '■en<=»  n t . '''his  can  be  accomplished  by  assigning  a 
very  short  ‘^yNOKY'*  to  each  user  defined  name  as  it  is 
defined , 

2)  To  allow  different  problem  definers  to  reference  the  same 
object  by  different  names. 

xvyvioFp?  niav  be  used  to  logically  group  seyeral  objects  for 
retrieval  and  analysis  purposes.  For  example,  to  generate  URA 
reports  for  only  those  npocESSES  which  were  to  run  in  batch 
mode,  each  of  the  PROC-SSE?  could  have  the  following  KEYHORD 
st  at  emen  t : 

K'^'YWORD;  EATCH  ; 

'islng  the  K^'Y^  facility  in  the  NAME-GEN  command,  all  the 
EPOCFSSF‘5  with  a KEYWORD  'BATCH'  cculd  be  retrieved.  Any 
d.-^sited  outputs  could  be  produced  by  UFA  at  this  point. 

'"""’’TBUTES  may  also  be  thought  of  as  qualifiers.  For  example, 
to  present  mol®  and  lennth  information  about  an  ELEMENT,  the 
followina  A TTR'I’P  UtFS  statement  might  be  used: 

MODE  VDMEFIC, 

L^-NGTH  8 ; 

-h®  AT'trTBD‘''r  s*-atement  can  be  used  to  fill  any  number  of 
requirements  for  snecifyinn  characteristics  of  objects.  For 
PPOCFRSF*',  processing  mode,  duration  miqht  be  given;  for  INPUTS 
and  0U’''F'1TF,  format  or  size  might  be  given;  etc. 

The  A'SFPT  statement  ma  v he  used  to  present  more  information 
about  an  existing  relationship.  For  example,  if; 

PF'IC^’FS:  grt-names  DERIVES  name  USING  number; 

an  appropriate  ASSEP"’  relationship  would  be; 

^c^qrpT  name  type  char,  number  typ»  integer; 

'1°L  provides  the  facility  in  KEYWORD  and  ATTRIBUTE  statements 
for  the  classification  of  objects  by  a criteria  which  can  be 
defined  and  expanded  as  the  project  prooresses.  The  additional 
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information  can  be  ai^lerl  at  any  time  durinq  the  project  without 
disturbing  th“  data  gatheroi  up  to  that  point. 

SECUPTTY  and  refer  to  the  definition  of  the  objects,  not 

♦■o  the  security  of  data  or  source  of  data  in  the  target  system. 

The  TPACE-K*‘Y  s'-atement  is  used  to  correlate  objects  contained 
in  different  lata-bases.  "he  security  level  in  a logical  system 
design  data  base  and  a security  level  number  in  a physical 
system  design  data-base  may  both  have  the  statement: 

TFAC^-K^Y:  secur  ity- level- key ; 


2.R.'  Proper b i^s  Out  puts 

"he  Dic-TONAPY  repor'-  presents  SYNONYMS,  the  DESCRPITION  and 
•f^YMOSOS  for  each  name  given  as  input. 

The  NAT-gF'i  command  can  retrieve  all  names  with  a particular 
KFYtfOFb  value  bv  using  the  KEY  parameter.  Reports  may  then  be 
generated  for  the  selected  names  by  utilizing  the  default 
facili'-ies  of  UPA. 

"he  A"TFISU"F  r« norn  presents  information  about  ATTRIBUTES  in 
the  proMf»m  statement  bv  presenting  those  objects  the  particular 
AT"PTPgTHS  a r*»  associated  with  and  corresponding 
ATTF  TPP"F-VA  LU’='S  . 


2.S.S  Proper  t i<^s  Com  rlt^teness  Checks 

None  cf  the  pronorties  are  ''necessary"  for  a complete 
description  as  it  is  up  to  tho  organization  to  impose  any 
reauirements  to  what  type  of  properties  are  to  be  incorporated 
in  ♦■he  docimena*- ion. 

However,  everv  nroperty  object  defined  should  he  used  at  least 
once  . 

1)  Fverv  KFYWOPP  should  APPLY  to  at  least  one  object. 

2)  Every  should  APPLY  to  at  least  one  object. 

R)  Pverv  should  APPLY  to  at  least  one  object. 

U)  Everv  SO'IPCF  should  be  the  source  for  at  least  one  object. 
Every  HFgri'>-xY  should  be  referenced  in  at  least  one  object. 
Fverv  "hxcf-K^Y  should  he  referenced  by  at  least  one 
c b 1 ect . 


^’roiec*  H ana  gemert 

All  ohdrc-  and  sra'^oment  facilities  in  URL/UPA,  which  are 
intended  to  improve  oraanization  and  management  within  the 
nroiect  and  present  information  about  the  project  describing  the 
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system,  is  ref^rrei  to  Proiect  Management. 


Project  Ma  nage  men  t Objects 

PPOBT.RK- rFFTN*‘P  - an  object  responsible  for  the  UBL 

description  of  one  or  more  of  the  objects 
beirq  described.  Usually,  the  OPL  names 
will  he  the  name  of  a person  in  the  form 
normally  used  in  the  organization. 

MATLBfX  - an  object  which  identifies  an  address  by 

which  information  may  be  sent  to  a 
oarticular  PPOPLEM-DSFINER . In  time 
sharing  systems,  which  provide  such  a 
service,  the  MAILBOX  would  be  the 
PFOBLYr-DEFINFE's  ID. 


2.^.2  Project  Management  Pelationshics 


PF'iPrRBTPLF-PPORLEr-DEFTNFP/RBSPONPIDLF  Fnp 

^ PFOBI.Fr-OFPT’IER  may  be  FFSPONSIBLF  for  the  description  of  any 
other  object,  an  j anv  object  may  have  a 
RF 'PCNSI  PLF- P L r**.- E FFIV^P  . 


M»TT  PCX/ APPLIES 

A PRO3LF*’-0EFTVi^P  may  hav^  a MAIT.BCX  and  a MAILBOX  may  APPLY  to 
a PPCPLEF-b?FIN?P. 


2.1.2  Pro  jec  t Management  Svr  ta  x and  Semantics 

The  objects  and  relationships  involved  in  describing  he  project 
management  asoect  of  a system  are  shown  pictorially  in  Figure 
2.'^.j  and  in  tabular  form  in  Table  2.9.1. 

The  PFSroy^I BLE- PRCPI FF-nEFIREE  statement  implies  that  the  giwen 
PROBLEM-DEFINFP  accepts  responsibility  for  the  UPL  description 
of  the  designated  ohdect:  it  is  assumed  that  any  guestions 
concerning  this  descrin*-ion  can  be  handled  by  the 
opOBl DF*'!  N F®.  \ aiven  object  may  have  only  one 

’»ESPCNSPTLF-P?''nLTr'.-ptfi»)j‘R^  ^ PROPLEM-DEFINER  may  be 

PF'^PCRST  9L=*  for  manv  object  descriptions, 

A onnpLTM-nEviF'^R  mav  have  only  one  MAILBOX,  but  a MAILBOX  may 
APPT  T to  any  number  of  PPOBL  FM-niFINERS. 
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4. 4. 

lOhTPCt.s  othpri  RFSPONSTPIF-  | | 

Ithan  SAILROX,!  PFOPT,^H-DEFINEP->|  PFOPLHM-I  KAILBOX 
IPPODIPF  |<-R^<?PONSIBLE  FOP|DFFINER  I<-APPt.IES 

I DFFIVFP  I I I 

---♦  ♦-———-4. 


f 4. 

I I 

IS-»  SAILBOKI 
TO  I 1 

I I 


Fiqiir*'  2.9.1  tjpL  atemon^-s  for  Describinq  Project  Nanageraent 


other  Obiects 


Except  Problem 
Def  i r.er 

Problem 

Def iner 

Mailbox 

Other  Objects 

PESPONSIBLF- 

PSOBLEM- 

DFFINEP 

Problem  Refiner 

PFSPONSIBLE  FCH 

MAILBOX  i; 

’'ail  box 

APPLIES  TO 

•"able  2.9.1 

Statements  for  nescribing  Project  flanageaent 

?.9.4  Pro1°c  t Pa  nag e men t Comraoii  Equivalents  and  Osage 

e meaning  of  the^e  terms  are  the  same  as  those  in  coition  use. 
“"hese  statements  are  intended  to  help  the  oroject  nanageaent. 
"^he  itplementai-i  on  fi.e.,  their  use  in  a particular  project) 
deopnds  on  ‘•he  nar*'icular  situation  and  the  standards  in  use  in 
the  organ ira  *■  ion  . 


project  ijanagement  Out  outs 

Tntormation  relevani-  ‘o  Drooet;^  management  can  he  presented  in  > 
FOPMATTEO  "ROBT’^P  ?”ATFFENT  for  appropriate  PROBLEB- DEFI  NEBS  and 
PATLPryT=‘S. 

""ha  c*""*  BASF  .sqpFtpy  report  gives  ♦'he  number  of  each  objects  of 
each  type  that  have  been  defined,  and  hov  many  have  SYNONYMS  and 
PE^c PTPTToss , This  report  can  be  used  by  the  project  leader  to 
r-^viev  the  degree  of  progress  in  the  project. 


2.^.5  Proiec  t nage  ment  Cow  pie  teness  Checl^s 

1)  Fvery  PPOBL  E»'-0  FFTVfp  should  be  PSSPONSIBLB  for  at  least 
cne  oMect. 


PAR^  r 


nr?F  FFOniPEMENTS  LANGUAGE  MANUAL 


PO/iniTTCS/HRL  TISE^^’S  MANUAL 


116 


?)  Ev«ry  obiect  shouli  h;ive  one  and  only  on<? 

PFE  PON  ST»1L3-P?OB LI'S- OFF  TNEP. 

•»)  Fvory  SATL'^ox  should  APPLY  to  at  least  one  PROBLEM- DEPINEP. 
IX)  Every  PPOBI.  FS-D  FFINFP  should  have  a MAILBOX. 


■>.  OWL  SYNTAV  ^NP  ‘JEMANTICS  BY  "’YPE  OF  OBJECTS 


•^he  full  and  detailed  syntax  of  tIPL  is  contained  in  Part  II  of 
this  document.  Section  3 contains  a suamary  of  the 

statements  in  each  section  vith  the  sections  in  alphabetical 
order.  Section  h oortairs  the  description  of  each  statement, 
within  a section,  statements  appear  in  alphabetical  order  by 
statement  name. 

In  this  section  the  Fections  and  Statements  are  presented  in  a 
different  order.  ""he  paragraphs  following  each  statement 
describe  the  statement  and  give  the  syntax  for  each  statement 
and  an  example  of  their  usage. 


As  in  Section  2,  the  explanations  of  URL  statements  include 
three  levels  of  precision: 

"must"  - denotes  that  this  is  checked  by  URA  and  not 

entered  into  the  data-base  unless  correct. 

"should"  - denotes  that  this  is  not  checked  by  URA  before 

stored  in  the  data-base  but  is  necessary  for  a 
complete  description  of  the  target  system. 

Some  of  these  "completeness"  checks  are  made 
when  producing  UFA  reports  and  warning  messages 
are  produced.  Others  can  be  made  by  the 
analyst  using  URA  reports. 


"implies " - 
and 
"mav" 


denotes  the  semantic  meaning  of  the  statement, 
•^his  is  rot  checked  by  UFA  nor  necessary  for  a 
complete  description.  Interpretation  is  to  be 
decided  by  the  Problem  Definer  and 
org  a nira  tion  . 


■"he  uoL  reserved  word  in  parentheses  after  the  syntax  notation 
for  a St ateiflpT^t-^  specifies  an  acceptable  abbreviation  for  the 
long  form  of  t^e  statement’s  reserved  word(s). 


"ha  word  "section"  is  used  in  UFL  to  denote  a number  of 
statements  and  in  this  naper  to  denote  a number  of  paragraphs, 
■^o  avid  confusion,  *-he  fist  letter  will  be  capitalized  when 
referring  to  a URL  Section. 


. 1 Order  of  Present  a tion 


3.1.1  Order  gf  the  Sections 
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T'hG  rpst  of  Fecfior  specifies  f.he  complete  syntax  of  the 
statements  for  each  URL  Section.  The  URL  Sections  are  presented 
in  the  order  shown  in  Table  3.1, 


3.1.2  order  of  S tat 9 went s wi  thin  a Section 

•"he  Facilities  of  U”  L to  state  an  information  processing  problem 
h^ve  been  described  in  section  2 in  order  by  a sequence  of 
different  aspec*-s.  "^he  particular  sequence  chosen  is  a natural 
one  in  which  to  l#»arn  th®  language.  It  is  also  a natural  one 
when  the  problem  is  being  defined  in  top-down  fashion.  In  this 
section,  within  each  UPL  Section  description,  the  corresponding 
n"!  s*atomentf;  are  ordered  according  to  the  aspect  of  the  system 
description  to  which  the  Statements  aoply.  The  aspects  of  the 
svstPKi  descrip’-ion  are  given  in  the  following  order: 

Svstpm  Plow 
System  Structure 
nata  Structtir^ 

Data  Doriva*-ion 
System  Size 
System  Dynamics 
System  Architecttire 
System  Propert ies 
Prelect  Ma  nage  men.*- 

‘^ince  Svs*-eiti  Pronortv  and  "roiect  Hanagement  statements  can 
appear  in  almos*-  evary  section,  they  are  given  only  once  in  3.2. 

Pegardless  of  th'->  order  in  which  statements  are  entered  into  the 
data-hase,  they  appear  in  the  FORKATTED  PROBLEM  STATEMENT  in 
a standard  order.  The  order  is  essentially  that  followed  in 
section  2 and  summarized  in  Table  3,1.  (The  order  in  which  the 
sections  (i.e.,  the  ♦vpes  of  ohiects)  appear  in  the  report  is 
♦■he  cne  in  which  the  types  of  obdects  were  listed  in  the  file 
used  as  ♦•he  inou^"  to  the  VAKE-RFN  command  and  to  produce  the 
’'ORaAT"'rn  pposlem 
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■''N'^TRFACE  or  “EA  L-WO^LD-FNTITY 

3.  3 

ivonr 

3.  4 

OUTPCT 

3.  5 

'ENTITY 

3.  6 

SET 

3.  7 

‘^'■LATirN 

3.  8 

GROUPS  and  ELEMENTS 

3.  9 

npoCESS 

3.  10 

TN'"FPVAL 

3.  11 

CONOI‘’irN 

3.  12 

EVEN  T 

3.  13 

PROCESSr  P 

3.  14 

REEo  npcr 

3.  15 

PESOU'CE-nSAGE-PARAM  STEP 

3.  16 

TJVT'’' 

3.  17 

PPOBLF''-DERT»!FP 

3.  18 

•n  WMO 

3.  19 

pvpx VF 

3.  20 

ATTFin  U'rp 

ATTFTBUTE- VATUE 

CLASSI'TOA  TION 

KETHO*'  r 

MA  ILRCY 

S'^CURT'^Y 

SO  riPCE 

SU  PS E'"'’’ IN G -CPI'" EET ON 

SYSTEM-PARAMETEF 

TP  ACE-  KEY 

REST  GNA'"E 

3.  21 

<;YNCMyH 


Table  ?.1  Order  of  URL  Section 


Stat  eaon » e Permit  tel  in  AjLiijost  Fverv  U^L  Section 

'"he  u^’l  eni»n  t s that  may  be  allowed  in  a qiven  URL  Section 

are  d-^nenden*^  on  the  tynes  of  objects  defined  by  the  section 
header.  where  it  is  illogical  to  say  that  an  ELEMENT  USES  a 
’’ROC'EfS,  to  sta^-e  h a t a PFOCSS?  nSEF  an  ELEMENT  would  be 
allowed . 

“^here  are,  however,  the  nPL  statements  related  to  System 
Properties  and  Project  Manaqement  that  can  he  used  within  almost 
anv  ?ec<-ion.  These  statements  ate  described  in  this  subsection. 

’.’.I  SYNOVTK  ftaiemen^ 

'’YVonyms  are  al’^ernative  names,  or  abbreviations,  that  may  be 
used  to  reference  a particular  object  name.  SYNONYMS  must  be 
uniiue  within  the  problem  statement,  though  an  object  can  have 
anv  number  of  ‘^YVONYKS. 
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Sy  n'-  ax: 

SYVONYKS  (STN) ; 

(list  of  svnony*  naaes) 

’^’xample: 

''or  a lorn  ran®  lik^'  ''d'»partments-an(i-e«ployees» " it  aay  be 
easier  to  reference  it  bv  specifying  short  synonyas: 

SYNONYMS:  dept-eap,  de; 

1.2.2 

■’’he  UIsrnip-^ioN  ^ta'- eraen''  allows  the  problem  definer  to  specify 
information  about  an  ohiect  in  a narrative  format.  There  are  no 
restrictions  on  what  is  allowed  in  the  narrative  description 
except  that  a semi-colon  cannot  he  used  inside  since  it  is  used 
to  denote  t^e  end  of  the  statement.  Any  number  of  DESCRIPTION 
statements  may  he  given  for  an  obiect,  but  all  are  combined  into 
one  DESCRIPTION.  Any  suhseguent  DESCRIPTIONS  are  concatenated 
to  the  current  nTSC*=  tftTCN. 

“^ynt  ax: 

o':scFrp'"inv  (dtsc); 


(narrative  description) 

’'xam  nle: 

■"o  describe  the  hiohest  level  PROCESS  in  the  system  being 
described,  the  following  DESCRIPTION  statement  may  be 
anpl icab le: 

DESCRIPTION; 


1 
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Syntax: 

KEYWOPr  (KEY>  

(list  of  keyword  names) 


’'xam  pie: 

'^ho  followinq  =!♦•  a+ement  iray  be  used  to  identify  particular 
r»oC''5SES  as  lowest- level  processes; 

kEYWOPD;  ’^IRWINAL; 

all  OPCCEEEE?  with  ‘‘he  KEYVORD  "TERMINAL"  can  be  subsequently 
retrieved  toqathar  and  analyzed  in  available  ORA  reports. 

■> . 2 . a aTTPIBUT'’?  sta  temen  t 

»TT»IPUTES  are  used  to  state  specific  characteristics  of  given 
ohdects.  ""be  s-TprenTF  name  desiqnates  the  name  of  the 
characteristic  and  the  ATTPT BUTE-VALUB,  the  value  or  magnitude 
of  this  characteristic.  The  ATTPIPHTE-VALtlB  may  be  either  a OPL 
name  cr  an  inteqpr. 

An  obioct  way  have  arv  number  of  ATTRIDHTES.  A given  ATTRIBOTE 
can  refer  to  any  number  of  obiects  not  necessarily  of  the  same 
t vno  . 

Pvntax: 

AT"’PTBM"'ES  (A-""?) , 

attribute  name  attribute-va lue  name 


attribute  name  attribute-value  name 


attribute  name  attribute-value  name 


’^xamnie : 

“^o  specify  ‘■hat  a particular  data  element  is  numeric  field  of 
lenqth  six,  ‘■he  followinq  statement  may  be  used: 

A’r"‘PIT>''TES:  '“yPE  NUMERIC, 

IpvGTH  ?iy  ; 

ms®. I 'statement 

The  A£S*'R’‘‘  statom*^nt  allows  the  Problem  Definer  to  assert  that 
one  ohdect  mus^  have  a particular  AT'ieiBH"'E  and  A TTF I BUTS- VALUE 
when  related  to  another  object.  An  object  may  have  a number  of 
AESVP"'  statement.s. 
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ax ; 

ASSERT  (ASP?)  ; 

(1  ist  of  names  followed  by  attributes 
and  attribute-values) 

’?xam  ole: 

If  PFrCFSS  qet-name  PEPIVES  name  USING  number,  an  appropriate 
ASSEPT  s’-atement  would  be: 

name  type  char, 
number  type  in teqer; 


PFS2QNS:plE:;PF  OPLEJl^miNIP  statement 

The  ppspOMSlBL^-PFObl '•'-nEFIvEP  Statement  specifies  that  one 
problem  de^'irer  person  is  responsible  for  initial  preparation 
and/or  maintenance  of  an  ob1  ect  description.  Only  one  problem 
definer  mav  he  deleqa*-ed  responsibility  for  a qiven  Section,  but 
mav  be  responsible  for  more  than  one  Section. 

'^yn  tax: 

»^FSP0n<5I  ETL'^-PFOHL?''-Df’'rTIF'’  (PPD) ; 

(name  of  responsible- 
problem-def  iner) 

^xam  rla : 

To  specify  that  '"ichel  Bastarache  is  responsible  for  the  URL 
description  for  a particular  obiect,  state: 

BPS  pops  IBLF-PCOPLFK-DE>:iNEP  MICHEL-  BASTARACHE; 

in  the  n^L  Section  for  that  oh-ject. 


2i’tement 

"■h  ? statpni®nt  allows  a description  common  to  several 

obiects  (and  available  in  a MSKC's  DESCRIPTION)  to  be 
referenced.  This  statement  may  occur  any  number  of  times  for  a 
qiven  ob iect . 

'^vnt  a X ; 

'•EF-M^'rO  (S'!) ; 

(list  of  memo  names) 

’’xaircl®: 

"•o  refer  to  a par*-icular  MFMO  on  programming  conventions 
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relevant-  to  the  d osc  r inti  on  of  low  level  PROCESSES,  the 
tollowino  ""av  be  aiven: 

SEE-MFMC:  PR  0(?  EAKMIN'1-CO  NVENTIONS  ; 


1.2.  P Sn^IPC®  Statement 

""he  SOUFCE  stateiPn*-  identifies  infornation  not  contained  within 
the  system  documentation  that  is  relevant  to  the  understanding 
of  the  system.  '"he  SOriPCE  may  be  a person,  a document  (such  as 
a practice  or  auideline),  etc.  Any  number  of  SOURCES  may  be 
rela*-€d  to  an  ob  iect  . 


V n t a * : 

SO’JRC?  (SRC) 

(list  of  source  names) 


’='xam  pie ; 

To  mate  reference  o a paper  writ^pn  by  Constantine: 

SOURCE:  CONSTANTINE; 

■"he  MET  description  of  ♦•he  SOURCE  name,  CONSTANTINE,  would 
probablv  soecity  relevant  information  such  as  name  of  paper, 
date  published,  etc, 

1.2.1  fFCUiITY  Statement 

The  SECURITY  sta*-e'nent  specifies  the  level  of  security 
associated  with  a given  ob-jpct's  tiPL  description.  Any  number  of 
s?c'’PTTI'^^‘^  mav  b-^  related  to  an  obiect. 

Syntax: 

SECN’5I'"v  (si;c) ; 

(list  of  security  names) 


Exam  pie: 

■"o  specify  that  the  TTPL  description  for  a given  object  may  only 
he  viewed  hv  company  personnel,  the  following  statement  may  be 
used  ; 

SECURITY;  COMPANY; 


’.2.10  IfiCF:;EEY  ilatement 

X tpace-key  (s  used  to  correlate  objects  which  exist  in 
diff^rer*  data-bases.  An  obiect  may  have  several  TRACE-KEYS. 
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Hynt  ax: 

•"PACF-K'Y  (•'KEY) ; 

(lis*-  of  trace-key  names) 

"xam  pie: 

'’he  securitv  level  in  a loaical  system  design  data-base  and  a 
secnritv  level  number  in  a ohysical  system  design  data-base  may 
ho*h  have  '•he  statement: 


"FACE-KEY:  security-level-key; 


■?.?  I^IJ?ZArE  Sect:  or. 

HEAL-WOF  Lr>-m>|-xr''EE  or  TK^ShfaC^S  are  named  objects,  outside  tha 
♦’arge'-  system,  tha*"  interact  with  the  system  being  described, 

Tf  ♦■he  svs'-‘=>ni  boinq  described  was  a payrcll  system,  one  possible 
would  be  the  employees  paid  by  the  system.  They  could 
be,  in  one  sense,  ♦•  h e customers  of  the  system. 

IN'^'^PFArE  fTN"?’) ; 

(list  of  interface  names) 


’ . 3 . 1 H ystPin-  glow  It  a ten  e£t  s for  IVTEPFACEE 

"he  EECFTVEE  s'-a'-ement  is  use!  to  specify  that  the  INTERFACE 
accepts  intorma*-ion  (OUTPUTS)  from  the  target  system. 

F^CEIV’^S  (?TVS)  ; 

(list  of  output  names) 

The  CFMFHATES  sta*-ement  is  used  to  specify  that  the  INTERFACE 
produces  intorma tio’'  ('’NPUT)  which  is  used  by  the  systea  . 

GENPFA''FS  (OFNS) ; 

(list  of  incut  names) 

The  FESPONSIBLE  s'-a'-em'^nt  specifies  that  an  INTERFACE  has  the 
resDorsibil  i ♦•  V of  maintaining  information  (SETS)  within  the 
ato  e t s vsto m . 

HESPCNS'-pL"  (R^SP) ; 

(list  of  set  names) 

"o  insure  compie*<.opc-s  of  the  problem  statement,  the  problem 
iefinpT  should  checv  that  every  Interface  either  GENERATES  some 
TNpr??;-  FECEIVES  some  OUTPU"  or  is  RESPONSIBLE  for  some  SET. 

Sr  TNTEFFAcr,  therefore,  can  interact  with  the  system  only 
•■hrouqh  «ECrrVTNg  On"PU"-S,  GENERATING  INPUTS  or  being 
«»E*'HCNSTBLr  '’'At  sft*^  . Tn  particular,  it  is  not  possible  to 
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(1<»<5ctibe  any  proc»>s5;in  performed  in  the  INTEPFACP.  If,  in  the 
system  descr  io^-ion , it  is  necessary  to  describe  processing  in 
the  TV?^FFACF,  then  it  should  t€  designated  as  a PROCESS  instead 
of  an  IVTFRFAcS.  See  section  4.1  on  system  boundaries. 

?.3.2  System  - St  ruct ure  statements  for  "INTERFACES 

"n  TNTFFFACE  may  be  part  of  one,  ard  only  one,  larger  INTERFACE, 
and  it  may  have  any  number  of  subparts  that  are  also  INTERFACES. 

n 9 't'  j 

(interface  name) 

surpaFTS  (SUSP) ; 

(list  of  interface  names) 

■"h“se  statements  permit  organisation  structures  to  be  specified, 
'"his  can  be  used  to  obtain,  from  ORA,  descriptions  of  the  system 
as  seen  from  a particular  part  cf  the  organization. 

' Ha  ta-neriva*:ior  s»a  tewen t s f cr  TNTSPFACFS 

Tn  the  tarset  system,  an  TN'"FPFACF  may  have  the  right  to  access 
information  of  -ertaln  classifications  and  categories. 

SFC!?FT'’Y-ACC'"J‘^-P  (SAF) ; 

(list  of  classification  names 
optionally  followed  by 
classification  levels) 


?.3.4  Projec  ♦■-‘*a  nage  ment  Sta  t ^ngnts  for  INTERFACES 

'FSPCVsr  PIP- PPOPt  Fw-Dr’='TNEF  Statement  may  be  used  in  this 
Fectirn.  bescriotion  and  syntax  of  this  statement  are  given  in 
-section  1.2. 


■’.1.^  System- Properties  Sta-  ements  for  I NTSR  FACES 

/'■ 

■"he  5^YMO»:v'*'5  , PF'^Cf:  PTTOK , SF'F-*'FF0,  KEYWORDS,  ATTRIBUTES, 
AFF'-PT,  S’^’CTrl-Y,  and  TEACF-K^'Y  statements  may  be  used  in 

"his  -Section.  Decker  iption  an1  syntax  of  these  statements  are 
uiven  in  section  1.2. 


■».4  INPUT  Section 

INppTF  are  information  that  is  produced  (GENERATED)  by 
TN-"F?fAr«'S  and  that  is  brought  into  (RECEIVED  BY)  the  target 
sys" en. 
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1 


(IMP) ; 

(list  of  input,  names) 

name  of  the  INPr’"  can  he  consi'iered  as  the  name  attached  to 
either  t h«  collection  of  data  values  or  the  physical  medium  on 
which  the  lata  values  are  recorded,  i.e.,  the  carrier  of  the 
data  values,  or  to  both. 


■’.ti.l  Sv "^low  £2£  IKPOTS 

■"he  names  of  ’•he  "N'^ERFACES  providinq  the  INPUT  are  given  in  the 
qr«jpp^"'-p  .statement, 

C^NEF  *"■'■[1  BY  (GEVP)  ; 

(list  of  interface  names) 

■"he  oh-ier*-  in  the  system  which  accepts  the  INPUT  is  given  in  the 
P’^'CEIVF’'  BY  sta‘'eraen^: 

FFCEIVED  '’Y  (’’CVP) ; 

(list  of  process  names) 

■"hese  s»  a ’■'’m  en*^  refer  only  to  ♦’he  logical  collection  of  data 
olemorts  value,  ani^  provide  a wav  of  stating  where  the  INPUT 
comes  from  ani  wha*-  PROCESS  must  accomplish  whatever  is 
n^'cessary  to  "accept"  it.  All  operations  on  the  data  element 
values  ITUS’-  be  specified  separately  in  the  definition  of  the 
PROCESS, 

Fverv  TNrU"  choul'^  be  GEFSRATED  by  at  least  one  INTERFACE  and 
’’EC’='IVF"'  by  at  least  on®  PROCESS, 


1,'J,2  Svs’-^m  - St  r ucT  iir  e Statements  for  IN  PUTS 

An  INPM"’  may  be  part  of  one,  and  only  one,  larger  INPUT,  and  it 
may  have  any  number  of  subparts  that  are  also  INPUTS. 


PA'’"' 


(name  of  input) 


SmPAPTS  (SUpo) 


(list  of  input  names) 


"ho.se  5;e  a*-ar*one  s allow  definitional  structures  (grouping  INPUTS 
♦•ogether  to  call  ’•h^m  by  a single  name)  and  high  level  data 
structures  to  be  specified.  Tlie  lowest  level  of  INPUTS  normally 
will  be  usfd  for  physical  documents,  messages,  cards,  etc,,  that 
flow  into  the  sv. stain. 


"o  describe  a collection  of  INPUT  cccurrences  (SET  of  INPUTS), 
’■h''  contained  statement  may  be  used  to  relate  INPUTS  to  SETS. 


PAR'" 
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COMTAI'^FC  (CNT’r))  ; 

(list  of  set  names) 

’’'his  FF"'  can  then  he  used  in  further  statement  of  requirements, 
''his  irioht  he  used,  for  example,  to  describe  a batch  of  inputs 
such  as  time  cards  which  are  to  be  treated  as  a unit  for 
nrocessi nq. 

An  TNE!/''  can  he  contained  in  any  number  of  SETS, 


3.4.3  Da  ta-S  tructure  JtaieiDgl'ls  for  TNPHTS 

"he  da^a  (C^ODP'^  and  ETSKENT S)  whose  values  appear  on  an  INPUT 
are  defined  via  the  CCMSTSTS  statement.  Each  data  name  used  in 
the  statement-  can  be  cptionally  preceded  by  a SYSTEM-PARAMETER 
to  define  <-he  number  cf  occurrences  of  the  data  value  that  may 
appear  on  'he  input.  The  CONSISTS  statement  only  specifies  the 
data  on  'h-’’  INPUT  and  implies  nothing  about  format. 

CONSISTS  (CST*^) ; 

(list  of  oroup  and  element 
each  name  optionally 
presented  by  a system- parameter . ) 

A complete  problem  statement  should  have  all  INPUTS  (which  do 
no'  have  SUSuapTS  s'atemerts)  broken  down  into  OPOUPS  and 
ELCr  ENTS . 

■^.'4.4  Da'a-Pgriva'ion  ‘^ta  tem  en  t s for  INPUTS 

T’he  n?ED  statements  specifies  those  PROCESSES  which  use  the 
information  available  in  'he  INPUT, 

US'='0 ; 

(list  of  process  names) 

’'his  implies  that  at  least  one  piece  of  data  (OPOUP  or  ELEMENT) 
on  'he  INPU''  is  boim  usTp^  •j'q  specify  the  manner  in  which  the 
INPUT  is  used  more  precisely,  the  DEPTVE  or  UPDATE  clause  may  ba 
us«d  in  conn unc' ion  with  the  USED  statement. 

UJ^i^D  fY 

(list  of  process  names) 

"0  DEPTV?  (DRV) ; 

(list  of  element,  group,  entity, 
set  and  output  names) 


us^n  FY  

dis'  ot  process  names) 

'-0  unCATF  (UPD) 


PAo? 
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(list,  of  elf»raent,  group, 

PT’f  1 ty  a pi  s<»t  names) 

An  IVP'I""  mav  he  by  any  number  of  PROCESSES.  Every  INPOT 

should  be  used  by  at  least  one  PROCESS. 

CLASSIPICA'^ION  of  an  INPOT  may  be  specified  with  the 
CLASSTFICA‘"ION  statmont: 

CLSS STFICA"ION _ _ ; 

(list  of  classf  icat  ion  names, 
each  oDtior.allv  followed  by 
a 1 vel  number) 

Any  PROCESSES  or  PEDCESSOPS  that  use  the  INPUT  must  have 
S’='CnRi"-Y-A~CFSS- RIOHTS  that  ma«-ch  the  classification  of  the 
TM^er . 


■* . U . 5 Systom-Oyn  amics  Sta  *emen  ts  for  INPtITS 

^or“  than  one  individual  instance  of  an  INPUT  may  occur  over 
somo  period  of  *■  imo.  ""he  number  of  instances  of  the  INPU*"  that 
occur  over  ’■ime  is  sta*-ed  through  th®  HAPPENS  TIHES-PEP 
stat  emen  t : 


(HA’') 


’TN’='S-P’^'=  ("INP) 


(svst  em-narameter) 


(in*-orval  name) 


Fverv  INPUT  should  have  a HAPPFNS  statement.  An  INPUT  can  have 
only  cne  H^ppvvs  statement. 

The  arrival  of  an  IKPU"  may  affect  the  processing  currently 
beirq  performed,  or  it  may  initiate  new  processing.  This  is 
described  via  ^he  TriOr.ERS,  '"EPHTNATES  and  INTERRUPTS 
s^  at  omen  t s; 


■^ICCERS  (TECS) 


(list  of  process  names) 


'EPriNA"'ES  C^P-S) 


Twry  (lE^S) 


fl  ist  of  process  names) 


(list  of  process  names) 


""he  arrival  of  an  INPUT  may  also  cause  an  EVENT  or  set  the  value 
of  a COFPt-'TON, 


CAUS’^S  (C5?) 


(list  of  event  names) 
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(FAK) 

TRUE  (T)  : 

(P  AK) 

(list 

o f 

con  dit ion 

names) 

FALSE  (F)  : 

(list 

of 

condi  t ion 

names) 

»ii  INFfi'^  mav  or  mnv  not  involve'1  in  any  syston  dynanics 
rola  ion  shins . 

f Proit^ot-»'anacTQHQnt.  Statements  for  IKPUT 

•^ho  oFSPONsr  RLS- 'J’CP  statement  may  be  used  in  this 
Section.  Description  and  syntax  of  this  statement  are  given  in 
section  3.2 

. 4 . Systom  - Pro  per  t ies  Stat  ements  for  INPUTS 

SYNONYMS,  nSSCPTPTION,  SEF:-«2MC,  KEYWOPDS,  ATTRIBUTES, 
i'SS*'PT,  SECUPITY,  SDUPCF  and  TFACE-KFY  statements  may  be  used  in 
♦■his  Sect-ion.  Description  and  syntax  of  these  statements  are 
given  in  section  3.2. 

3.P  OCTPU^  Section 

OUTPU"'S  ar®  information  that  is  produced  (f?ENERATED)  by  the 
target  system  (PROCrssPS  within  the  system)  and  that  goes  to 
(are  FECEIV^D  BY)  INTEPFACES. 

OUTPUT  (CU”)  ; 

(list  of  output  names) 

"he  name  of  the  'lUTPUT  can  be  considered  as  ♦he  name  attached  to 
either  or  the  collection  of  data  values  or  the  physical  medium 
on  which  the  data  values  are  recorded,  i.e.,  the  carrier  of  the 
data  values  or  to  both. 


■'.'.1  Systom- glow  sta  t®ments  for  OUTPUTS 

The  names  of  the  P-ocf''si's  producing  the  OUTPUT  are  given  in  the 
OENEPATID  Statement. 

DEUEFA^ED  PY  (O.FND) • 

(list  of  process  names) 

"he  TNT*'?F?CF.s  which  accept  the  OUTPUT  are  given  in  the  RECEIYED 
PY  statpifont; 

nuC''TVr''  PY  C’CVD) ; 

(list  of  interface  names) 
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’"h'^so  R+itompn*?!  rpf®r  only  to  the  loqical  collection  of  iata 
f»lemrntF.  vein's,  ani  Frovid<“  a way  of  stating  what  PROCESSES 
must  produce  the  onTPU?  and  where  it  must  be  transmitted  to. 
All  operations  on  the  data  element  values  must  be  specified 
senarat#»ly  in  the  definition  of  the  PROCESS. 

Every  CttTP'tr  should  be  OENFRATEb  by  at  least  one  PROCESS  and 
RECEIVEn  bv  at  leas*-  cne  INTERFACE. 


1 . S . 2 System- Str uctu re  Statements  for  OUTPOTS 

An  OUTPUT  mav  he  part  of  one,  and  only  one,  larger  OUTPUT,  and 
it  may  havo  anv  numhrr  of  sabparts  that  are  also  OUTPUTS. 


PAS"^  

(name  of  output) 


SUBFAP'^S  (SnpP) ; 

(list  of  output  names) 

'"hesG  stat^^ments  allow  definitional  structures  (grouping  OUTPUTS 
together  to  call  them  a single  name)  and  high  level  data 
s*Tucturer;  to  bo  sp'^cified.  ""he  lowest  level  of  OUTPUTS 
normally  will  ha  used  for  physical  documents,  messages,  cards, 
»tc.,  that  flow  out  of  ♦■he  system. 

"^o  d«3scrih*»  a collection  of  nuTPO""  occurrences  (SETS  of  OUTPUTS) 
♦■he  rcN"’A’'V*' p statement  may  be  used  to  relate  OUTPUTS  to  SETS. 

Cos-ArnFp  (CNTP) ; 

(list  of  set  names) 

"♦his  SF " can  then  he  used  in  further  statement  of  requirements. 
This  miaht  he  use),  for  example,  to  describe  a batch  of  outputs 
that  are  to  be  produced  as  a unit. 

An  onTPU""  can  b"  contained  in  any  number  of  SETS, 


for  OUTPUTS 

"he  data  (C'’oups  and  ETEFENTS)  whose  values  appear  on  an  OUTPUT 
ar^>  defino-1  via  th®  CONSISTS  statement.  Each  data  name  used  in 
the  statement  can  optionally  preceded  by  a SYSTEH- PAR AMETER 
to  defire  ♦•h“  number  cf  occurrences  of  the  data  value  that  may 
appear  on  t h nu?pu-".  The  CONSISTS  statement  only  specifies  the 
■lata  on  tho  o’jtpU"  and  implies  nothing  about  format. 

CONSISTS  (TSTS) : 

(list  of  group  and  element  names, 
each  name  opticnally  preceded  by 
a system  parameter) 


PAP- 
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A problpjo  shcuLd  have  all  OUTPUTS  hha'"  do  not  have 

"'uppAPTS  st-atements  broken  down  to  OBOUPS  and  ELEKEHTS, 

•'’h*  CL»‘'‘5IF'’CA‘?T  ur  of  an  OUTPUT  may  he  specified  with  the 
CLAS:FTT'TrA’’:OU  sta«-iiierit; 


CLASSIFTCA-rON ; 

(list  of  classification  names,  each 
on*"  ion  ally  followed  by  a level  number) 

Anv  PFCCESSFS  or  PPOCPSSOPS  that  use  the  OUTPUT  must  have 
SFCUW^'Y-ATCFFS- p lU'lTS  that  match  the  classification  of  the 
OU’^PUT, 

Pa  '•a-  b erivat  ion  Sta  tpugn  t s fcr  OUTPUTS 

'’’he  rEFIVKU  statement  specifies  those  PROCESSES  that  derive  some 
information  presented  on  the  OUTPUT. 

bEPIVEP  (uryu) ; 

(list  of  process  names) 

■"his  s*-atei«ent  implies  that  at  least  one  piece  of  data  (GROUP  or 
ELE^FN"")  on  th°  O^rpUT  is  DFPTVFr. 

■"o  specify  mor°  precisely  how  the  OUTPUT  is  derived,  the  USING 
clause  may  he  U3<»d  in  coniunction  wi  "h  the  DERIVED  statement. 

np^iVFr  py  (DVVD)  

(lis*  of  process  names) 


U'^TUG 

(list  of  in  out,  set,  entity,  group 
and  element  names) 


vstea-  Uyn  amics  Statements  for  OUTPUTS 

more  than  one  individual  instance  of  an  OUTPUT  may  occur  over 
som^  perioi  of  time.  ""he  number  of  instances  of  the  OOTPUT  that 
occur  over  time  is  stated  through  the  HA  PPENS/'"INES  PER 
sta*^  emer  t ; 

HAPPENS  (UAP) 

(syst  em- par ameter ) 

ren  (""T*  P)  ; 

(interval  name) 

Pvery  otiTP’U"  should  have  a H APPFNS/TIUES  statement.  An  OUTPUT 
can  have  only  one  HAPP^US  statement. 
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1 . S . rro1ei-:t-ManaTO  ment  Statements  for  OUTPUTS 

’''he  PECI'ONSIRLF- opoSLEM-nSFIVEF  s'-atement  may  be  used  in  this 
s*»ctior.  Tescri  p'-ior  and  syntax  of  this  statement  are  given  in 
seo*- iop  3.2. 


System -Pro  pert  v Staten  «nts  for  QtrrPUTS 

"’he  SYNINYMS,  DF  SC?T  P'^'IDN , SFt-MEKC,  KEYWORDS,  ATTRIBUTES, 
ASS'='P"',  SECUPI"'Y,  SOURCE  and  TRACE-KEY  statements  may  be  used  in 
♦•his  Section.  Description  and  syntax  of  these  statements  are 
given  in  section  3.2. 


3.^  ENTITY  Section 

An  ENTITY  is  a collection  of  information  manipulated  (USED, 
DERIVED  and  UPDR^FD)  hv  the  target  system.  An  ENTITY  differs 
from  an  TNR'JT  or  nri''’Fur  in  that  it  is  information  maintained 
entirely  internal  to  the  system  and  can  never  cross  the  system 
boupcaries  (i.e.,  o-nEPA'’FD  or  RECEIVEr). 

INPUTS,  pU’^onTE  and  ENTTIFS  are  similar  constructs,  though  only 
h‘3  logically  connected  through  RELATIONS. 

ENTITY  fENT)  ; 

(list  of  en*-ity  names) 

In  many  annl  ica*- ions , the  usage  of  ENTITIES  is  synonymous  with 
logical  records.  '=‘or  example,  if  an  employee  payroll  processing 
system  were  heino  designed,  the  information  needed  about 
salaried  and  hourly  eiPDloyees  might  he  stored  on  records  which 
would  b«'  defined  as  ENTITIES. 


Sy st.^m  E» riictu re 

^o  descrih*'  a collection  of  ENTITY  occurrences  (sometimes  also 
called  a file)  the  CCN'"AINED  statement  may  be  used  to  relate 
’=’NTI"’TES  to 

CONTA^NFr  (DN'nn)  . 

(lis^-  of  set  names) 

“"his  SF’'"  can  ♦h'^n  b®  us^d  in  further  statement  of  requirements. 
This  night  b*^  ii^ed,  for  example,  to  describe  a file  of  employee 
records  which  are  ♦o  be  treated  as  a unit  for  processing. 

3.6.2  rata-S*;ucture  Statements  for  ENTI TIES 

'"he  data  (UROUpe  and  ELEMENTS)  whose  values  appear  in  an  ENTITY 
are  define!  via  the  CC'ISI^TE  statement.  Each  data  name  used  in 


T'  1^  ^ 
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'•ho  s'-atemont  r^n  be  cp'-ionelly  preceded  by  a SYSTEM-PARAMETER 
to  define  the  numhor  of  occurrences  of  the  data  value  that  may 
apoear  on  the  '^NTT’^'V  . 

■"he  CCNSTS'''S  statement  orlv  specifies  the  data  on  the  ENTITY  and 
implies  nothinu  about  its  format, 

CnN5;TS"'S  (CSTS) ; 

(list  of  qroup  and  element  names,  each  name 
optionally  preceded  by  a system  parameter) 

A complete  problem  statement  should  have  all  ENTITIES  broken 
down  to  CROUPS  and  FIEMevts. 

"^o  specify  that  each  ENTITY  occurrence  may  be  uniquely 
idontified  by  one  or  more  keys,  the  IDENTIFIED  statement  is 
used  . 


TDFN'TFTED  (IPD)  ; 

(list  of  group  and  element  names) 

"•he  PFL»TED  statement  specifies  a logical  connection  between  two 
ENTITIES  . 


RELATED  (PEL) 


(name  of  entity) 


VIA ; 

(name  of  relation) 

This  implies  thit  given  one  of  the  two  ENTITIES,  information 
from  the  other  ran  be  found. 


3.*).  3 Data-nerivatjor  Statements  for  ENTITIES 

■"he  USED  statement  specifies  those  PROCESSES  which  use  the 
information  availal'le  in  the  ENTITY. 


(list  of  process  names) 

■"his  statement  implies  that  at  least  one  piece  of 
'=‘LEriEN'")  in  the  ENTITY  is  being  USED. 


data 


(GROUP  or 


"o  specify  the  manner  in  which  the  ENTITY  is  USED  more 
precisely,  the  DEFTV*^  or  UPDATE  clause  may  be  used  In 
con  1 urct ior  with  tho  USED  statment. 

U5>'’D  EY 

(list  of  process  names) 

TO  pfftvt  (P^V)  

(list  of  element,  qroup,  entity 
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set  sn-1  output  nanes) 
or  nSED  by  a to  'IPDATE  lata: 

nSED  PY 

(15  St  of  process  names) 

"’o  L'^rA"’='  ('JPD) ; 

(list  of  element,  qroup, 
entity  and  set  names) 

DFPIVEO  statement  specifies  those  PROCESSES  which  derive 
some  information  presented  in  the  ENTITY, 

qpi?TVEn  (peyp) 

(list  of  process  names) 

"his  statement  implies  that  at  least  one  piece  of  data  (GROnP  or 
ELEMENT)  in  the  ENTITY  is  PSFTVFD.  To  specify  the  manner  in 
which  tha  FfjTt^Y  is  derived  more  precisely,  the  PSING  clause  may 
be  used  in  condunc^ion  with  the  DEFIVED  statement. 

n’^'PTV^n  PY  (PP'^P) 

(list  of  process  names) 


'JSING ; 

(lis*-  of  element,  qro'ip,  entity, 
set  and  input  names) 

The  qpDA'^F’^  statement  specifies  those  PROCESSES  that  modified 
some  information  presented  in  the  ENTITY. 

PPOA^TD  (nppp)  ; 

(list  of  process  names) 

"his  statoinopt  implies  tha^  at  least  one  piece  of  data  (GROUP  or 
^'I.EfENT)  in  the  '^NTI’^Y  is  UPDATED. 

"o  specify  more  precisely  the  manner  in  which  the  ENTITY  is 
updated,  th®  U‘?I  NG  clause  may  he  used  in  coniunction  with  the 
UPDATED  statement. 

updated  RY  (UPDD)  

(list  of  process  names) 


U^rNG ; 

(list  of  element,  groan,  entity, 
set  or  input  names) 

’‘•very  ENTITY  dofippd  should  be  USED,  DERIVED  or  UPDATED  by  at 
least  ore  PROCESS. 

"he  Cl ASSIEICA"t0M  an  FN^ITY  may  he  specified  with  the 
rLASST»='TCA"ION  Statement: 
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CLASSTPTCA'^ION ; 

(list  of  classification  names,  each 
optionally  followed  by  a level  number) 

Any  PForfSSES  or  PF?C'='SSOfs  that  use  the  ENTITY  must  have 
*'ECUP'"TY- ACCESS- PTT.HTS  ♦■hat  match  the  classification  of  the 
'•VTITY. 


3.8.4  System- Size  Sta  teaent s for  ENTITIES 

'♦'he  CAFr"*I»LITY  statement  specifies  the  maximum  number  of 
occurrences  of  a particular  ENTITY  in  the  target  system  at  any 
tine . 


rAKPTNALT'Y  (CAPO) 


(system  parameter) 


Every  '■NTi-y  should  have  a CAPDINALTTY. 


■^.f.5  System  - Dynamics  ftatemenjts  for  ENTITIES 

■"he  VOLATILITY  Statement  specifies  the  manner  in  which  an  ENTITY 
charges  ov^r  time.  Since  there  are  many  different  ways  in  which 
an  FNTI'"Y  may  be  changed,  this  information  is  entered  yia  a 
comment  entry.  ’"he  type  of  information  specified  in  this 
statement  mioht  h®  the  number  of  times  a particular  ENTITY 
occurrence  would  he  updated  in  a giyen  time  interval,  how  often 
ENTITY  occurrences  would  he  deleted,  and  often  created,  etc. 

V0LATILT'"Y  (VOLl  ; 


(comment  entry) 

'•very  '•NTI'^Y  should  hav"  a VOLATILITY. 

■’.6.6  Pro1ect-Ta  naae  m^nt  Sta  tgments  for  E NT  I T I SS 

■"he  PF.SPO’JST  31"- P'^OST '■'•-PFFINSE  statement  may  be  used  in  this 
Se-rior.  eescrin^ion  and  syntax  ot  this  statement  are  given  in 
sec*-ion  3.2. 

3 . 6 . T System- Proper*:  ies  S»at  ement  s tor  ENTITIES 

-he  SVNONYES,  n-  SCP  PTJON  , SEE-KEMC,  KEYWCPDS,  ATTRIBUTES, 
ASSFFT,  SECUPITV,  .son»C2  and  TRACE-KEY  statements  may  be  used  In 
♦■his  Section,  description  and  syntax  of  these  statements  are 
eivon  in  s'^ction  3.2. 
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3 . SFT  ion 

\ SET  is  a c:oll<*c+-ior  of  oup  or  more  ocurrences  of  objects  that 
contain  or  rarrv  ilata  values.  A SFT  may  represent  a collection 
of  *'M7lTrss,  IVPP’^E,  or  OUTPUTS,  but  not  a combination  of  these 
object  types.  That  is,  a SET  cannot  consist  of  both  INPUTS  and 
OUTPUTS. 


(list  of  set  names) 

Where  "PTITIES  may  be  thought  of  as  logical  records,  a SET  may 
he  thought  of  as  a logical  file.  In  any  case,  a SET  should  be 
used  according  o the  algebraic  sense  of  the  word  "set." 


1 Sy stem- ^low  S a toment s for  SETS 

“^he  eESPOMSI  BL'’- "K"''' '='ACE  statement  specifies  those  INTERFACES 
♦■ha*’  have  ♦•he  responsibility  of  maintaining  the  information  in 
♦ho  SFT. 

nrSPCNSIBL’^-T’J’^’ER’^ATI  (PINT) ; 

(list  of  interface  names) 

Fv‘’»rv  SF’*’  should  have  at  least  one  responsible  INTERFACE. 

3.  ■’.2  System-  "^t  r uct  u re  st  atements  for  SETS 

Th*»  cipcPTc:  3^1  statements  specify  the  manner  in  which  a 

particular  is  related  (in  the  algebraic  sense,  again)  to 

other  SETS  in  th“  ♦■a  rge*-  system. 

A SF""  can  be  a of  a larger  (or  equivalent  size)  SET: 

t^rtqCfT  (SS-)  _ ; 

flis*-  of  se*  names) 

A S’=’T  ran  also  have  a number  of  SUESFTS: 

SUBSETS  (SS'^S) ; 

(list  of  set  names) 

*'or  example,  a da^-a-^'as'*  may  be  defined  to  describe  all  the 
in^'ormation  maintained  bv  the  target  system.  The  data-base  may 
be  defined  to  be  a ♦'FT.  Smaller  collections  of  data  in  the 
data-base  such  as  tiles,  etc,,  would  then  be  defined  as  SUBSETS 
of  t h«  d ata- base  . 

■"he  suns*'”'"INU-CPTT''EIA  statement  specifies  what  data  determines 
how  a SET  is  to  he  subsetted. 

SUBSi'''TT*jr,-CFTTE'»IA  (SSCA) ; 
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flis^  of  subsetting-criterion, 
element,  and  group  names) 

Tf  a has  SUBSETS,  its  SUBSETTTNG-CPITEPI A should  be  defined 

also . 


3 Da  »a-Structuc°  ftateraerts  for  SETS 

•^he  Cf'NSIST':  statement  specifies  the  data  contained  in  the  SET 
and,  cptionallv,  tha  number  of  occurrences  of  this  data  in  the 
SET , 

COKSTS'^S  (TSTS)  ; 

(list  of  entity,  input  or 
output  names,  ootionally 
oreceded  by  system- 
parameters) 

'•very  SE”  should  CONSIST  of  at  least  one  ENTITY,  INPUT,  or 
OUTPUT. 

3,  "^.4  Da  t a- Derivation  s_ta_tpments  f cr  SETS 

'"he  USED  statemen*-  specifies  those  PBOCESSSS  which  use  the 
information  available  in  ♦•he  SET. 

USE"*  ; 

(list  of  process  names) 

•"his  implies  that  some  data  within  the  SET  is  being  USED. 

■"o  specify  the  manner  in  which  the  SET  is  USED  more  precisely, 
the  or  UpoA"’-'  clause  may  be  in  conjunction  with  the  USED 

sta*-  eiren  t . 

US'^D  FY 

(list  of  process  names) 

TO  rEpTV’'  (POV) ; 

(list  of  element,  group,  entity, 
set  and  ou’^put  names) 

or  USED  by  a pROC^''S  to  UPDATE  data; 

US’'D  PY 

(lis*’  of  process  names) 

""0  UDPAT^-  ('1"D) — — - — 

(list  of  element,  group,  entity, 
and  s®t  names) 

'"he  DEPTVED  statement-  specifies  those  PROCESSES  which  derived 
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so’no  in f orir \ ion  presRr.tpd  in  the  SET, 

r,!70T7jn  (D07D) ; 

(lis'-  of  process  names) 

"his  s'-atement  implies  that  a*;  least  one  piece  of  data  (ENTITY 
or  ouir'tT)  in  ♦•he'  is  TERIVED.  To  specify  the  manner  in 

which  th®  •^»7TI"Y  or  GUTPU'^  is  derived  more  precisely,  the  USING 
clause  mav  ho  used  in  coriunction  with  the  DERIVED  statement. 

PE'5TVED  PY  (DhVD) 

(list  of  process  names) 

USING — ; 

(list  of  element,  qroup,  entity, 
set  and  input  names) 

7ha  UFnA"‘E'^  statement  specifies  those  PROCESSES  that  may  modify 
info  rira  ♦■  io''  in  *he 

tl^’DATVp  (unpp) ; 

(list  of  process  names) 

"his  s'-a  ♦■emer  t implies  tha^"  at  least  one  piece  of  data  (ENTITY) 
in  the  SF"  is  mpdaTFD. 

"o  specify  more  precisely  the  manner  in  which  the  SET  is 
updated,  the  US"  NO  clause  may  he  used  in  con'junction  with  the 
nPDATFD  statement. 

UPDATED  UY  (UPDO)  

(list  of  process  names) 


U'^ING — ; 

(list  of  o leme  rt , qro  up , entity, 

<5ot  Q*-  i r nut  names) 

Every  defined  should  he  USED,  fEPIVED  or  UPDATED  hy  at  least 

one  FFf^C^SS. 

"he  DEPTVA”ION  s’‘a*eirer<‘  should  he  used  to  specify  the  rules  for 
derivinq  occurrences  of  data  in  ♦'he  SET.  Since  there  are  many 
di^forent  wavs  in  which  this  data  may  be  derived,  this 
information  is  presented  via  a comment  entry.  The  type  of 
information  specified  in  this  statcmnt  m iqht  be  what  value  a 
par^’icular  eleeeN"  ir  an  ENTITY  must  have  to  he  entered  into  a 
f*-c. 

nEPivs^Tr*!  (DPV'l)  ; 


(commen  t *>n  ♦ry) 

ryery  Sf"  should  have  D~PTVA"'TON  specified. 
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*hp  CLASSI^’ICA'^ION  ot  a SFT  may  he  specified  with  the 
rLASSiFTCA’^TCN  statement; 

CLASSIFICA"’TOM ; 

(list  of  classification  names, 
each  op'-ionally  fcllowed  by 
a level  number) 

Anv  PROCESSES  or  PFTCFSSOFS  '■hat  use  the  SET  must  have  SECORITY- 
ACC»=‘FS-F  nUTS  ♦■ha'-  match  the  classification  of  the  SET. 


3.'^.  5 Sy stem- ^i7 o Ft  atemonts  for  RETS 

▼ he  CA'=DIN»L''”''Y  s'-atement  specifies  the  maximum  number  of 
occurrences  of  data  obiects  in  the  SFT  at  any  one  time. 

C'^DINAT  T^Y  (CARD)  ; 

(sys'-em  parameter) 

▼verv  SET  should  have  a CARDIN ALI'^Y. 


3, ’’.ft  fystom- Dynamics  Statements  for  SFTS 

The  VOLA  Tltl'^Y-'^  F/"  and  V0I.A'''ILI7Y-f«E?1QEP  statements  specify  how 
a SFT  changes  ov ar  t j me . Since  there  are  many  different  ways  in 
which  a SE^  may  be  chanced,  this  information  is  presented  via  a 
romnert  entry, 

■'he  VOT  A TTT^I  ■'Y-S  E"  statement  specifies  the  mann<“r  in  which  the 
en'ine  set  chances  over  '■ime.  The  tvoe  of  information  specified 
in  *-his  statemen*-  micht  he  the  numher  of  times  members  are  added 
♦o  the  SFT,  members  are  updated,  etc. 

VCLA  "IT.TTY-S'^T  fVCT'^); 


(CO m men ♦ en  try) 

■"ho  VOLA Till "Y-l Z^BE F statement  specifies  how  the  members  of  the 
▼ET  chance  over  time.  The  type  of  information  specified  in  this 
stitemcr'-  mich*-  be  the  number  of  additions  to  the  SET  of  a 
nar^icular  ENTITY  type,  the  number  deleted,  etc, 

VfLATTLTTY-'*E1B’='P  (VOLE); 


(comment  entry) 

'■very  SFT  should  have  VOl  ATT  LI  TY- 5 FT  and  VOLATILITY- HEKB  ER 
sAa^epents  qiven  for  them. 
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1.7,7  Pro1^ct-’*^naapmpnr  StatPmer.ts  for  SFTS 

T'ha  ’JFrpoN'^T  3L?- PPCR  T FM-rFFT  N£F  s^-atement  may  be  used  in  this 
Section.  Descrip^-ior  and  syntax  of  this  statement  are  given  in 
spc* icn  1.2. 

7.7.1  FystP'n  - Pro  pert  ies  flat  erne  nts  for  S ETS 

•"ho  .1YN,0»:Y‘'1  , ^ESC^rPTION,  SEE-'-EKC,  KEYWORDS,  ATTRIBUTES, 
AS'T’n'T,  P’^C'TPITY,  and  ‘^EACF-KEY  statements  may  be  used  in 

this  Section.  Description  and  syntax  of  these  statements  are 
qiypn  in  sec^’ion  3.2. 


3.9  PELATTQw  flcMon 

n is  a name^  loqical  connection  between  two  ENTITIES 

parcpiypd  hy  the  Problpm  Definer.  Any  URL  name  may  be  used;  the 
most  moanimful  name  to  ’’he  Problem  Definer  should  be  one  which 
denotes  the  connected  ENTT"'I3S. 


F'=’L»  TTOV 


(list  of  relation  names) 


Tf  a system  were  beirq  described  that  consisted  of  ENTITIES  for 
women  and  ’=’NTTT^ES  for  men,  a possible  PPLATION  to  connect  these 
'“NTITIES  minht  he  "spouse.” 


7.7.1  Pa  ta- S t rue  tur j Statements  lor  RELATIONS 

n qT-’^(,pr\i  5*-a*-empn*-  specifies  the  names  of  the  ENTITIES  that  the 
7''LA’'Tr‘'  connects  and  t.he  direction  of  the  connection.  The 
dir®ctior  is  let i red  hy  the  order  of  the  ENTITY  names  in  the 
statement:  fro”"  t-he  left  (first)  ''N"'ITY  to  the  right  (second) 
’^NTTTY.  "he  '"irst  EKTI"Y  can  he  considered  the  owner  of  the 
'»’=’LA"ION  and  the  second  ENTITY  the  member  of  the  RELATION. 


PETWEtN  

(name  of  entity) 


ANT ; 

(name  Dt  entity) 

Examole:  siTtjppjj  npp  pm  wTh-- ^vccRI  AND  HOUR  L Y- EM  PLOY  BE-P  ECOPD: 

"he  FFLe^ION,  up P A^T M EN'-TO-HOU PL Y-EMFLO YEE,  denotes  a logical 
connection  be*weon  two  ENTITIES,  DEP APTH FNT- P ECOR D and 
>iouply-^"PLO  YEF- =^r'"PD.  The  direction  is  from  DEPARTMENT- RECORD 
*o  HOHPI  Y-ew  ploy  EE-t' Fconc.  The  DFPAPTMENT-F  ECORD  is  the  owner 
and  HorTnLY-EfPnYMf^-FECOPD  the  member  of  the  RFLATION. 

''nlv  on"  between  statement  ran  be  aiv^n  for  a particular 
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®’='LATION,  hut  each  *?T'LATION  should  have  a BETWEEN  statement 
nivor  for  it. 

The  AfSCCIiTEn-P AT*  statement  specifies  those  GKOUPS  and 
ET.’='*1  EN""?  that  contain  information  specifically  about  the 
P'^'LATION  and  are  not  necessarily  CONTAINED  in  either  ENTITY. 

ne'^OCIA'^FD-DA'^A  15^ ; 

(list  of  element  and  group  names) 

’.^.2  Pa  ta- Deri vat ion  Eta  temen  ts  for  FEL  ATIONS 

A '1 A TN'^AIN^P  EY  star  ement  designates  those  PPOCESSES  which  add, 
delete  or  modify  the  connec*-ion  occurrences  between  the  ENTITIES 
that  are  connected  by  this  RELATION. 

EMN'^AINFO  BY ; 

(list  of  orccess  names) 

A PLLA"Tt>N  can  he  A TK^AINEP  by  several  PROCESSES,  and  every 
OELA'^ION  should  he  EAINI'AINEn  hy  at  least  one  PROCESS. 

The  PEFIVATTON  statement  should  be  used  to  specify  the  rules  for 
deriving  occurrences  of  the  RELATION  between  the  ENTITIES  . 

Since  there  are  many  different  ways  in  which  this  data  may  be 
darived,  this  information  is  oresented  via  a comment  entry.  The 
tyno  cf  information  specified  in  this  statement  might  be  what 
ar®  the  restrictions  in  relating  two  ENTITIES,  which  PROCESSES 
may  forma  *-he  relation,  etc. 

''S'’  IVATTON  (PFVN)  ; 


(comment  entry) 

Every  FFIA‘'’TO*l  should  have  a DFRIVA''ION  specified. 

1.'’.  3 Svst°m-  Ei7°  Sta^mer^ts  £or  F El  ATIONS 

A C"' ‘NFCTTVT "■  Y statement  specifies  the  number  of  ENTITY 
ocrurrerres  of  thf  first  (right)  ENTITY  that  are  related  to  a 
pumher  of  ’’►j'l'T-.y  occurrences  of  the  second  (left)  ENTITY. 

CnNNFC'’TVI'"Y  TR 

(syst  em- parameter) 

TO  ; 

(r.vst  em- para  meter) 

If  a particular  fn''I''’T  occurrence  may  be  related  to  only  one 
other  FNTI'Y  occurrence,  the  CONNECTIVITY  is  1 to  1.  If  a 
particular  EN'''ITY  occurrence  may  be  related  to  one  or  more 
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fv-n-r-jY  occurrenrrns  h.-?  CONNECTIVITY  is  one  to  many.  The  right. 
an'1  lef*  SY'^"' EM- '^AF  A E'^EF  S in  the  CONNECTIVITY  are  intende«1  to 
correspori  ♦•o  ♦'h"  right  and  left  ENTITIES  given  in  the  BETWEEN 
St  emen  ^ . 

Fv-Ty  OFLA'^IOV  should  have  one,  and  only  one,  CONNECTIVITY. 

A CAPDIKAL'^TY  Statement  specifies  the  maximum  number  of 
connec*-icn  occurrences  for  this  PELATION  . 


C A'’  P IN  AT  y-v  I s 


(svst  em- parameter) 


Every  FET.ATION'  should  have  one,  and  only  one,  CARDINALITY. 


I.g.n  Pro-jec  t-**anaqemer.'*-  Eta  tements  for  PFLATIOyS 

'T'*,.,  nTTcpavsT  pyr_  pppnT  Statement  may  be  used  in  this 

EecT-ion.  Osscriotion  and  syntax  of  this  statemnt  is  given  in 
sect icn  T. 2 . 


T.'l.F  ? Ys»em  - T>ro  port  jes  Etat  ement  s for  P ELAT  IONS 

■"he  SYVr‘’Y''S,  ic^l  FirON  , .E  E^- -y  yr  , KEYWORDS,  AT'T’FI  BUTES, 
ASST'cT,  SECriFI'"Y,  .'^OPPC?  and  TPACF-KEY  statements  may  be  used  in 
this  ser*-ion.  noser  iption  and  syntax  of  these  statements  are 
niven  in  section  ?.2. 


Tx  amol  e of  a " o tuple  te  ? - 1 ATI  CN  Section 

^''LA'TIOK  1enartmen*'-to-hourlv-emplovee; 

ASSOCT  A -EP- PAT'A  is  1 as^- lepat  tment-change ; 

A^TRIEPTF  -S  f r equen cy- of- use;  high; 

nr-ypT7f;  d“n a T* m o n ♦ - Tec o pd  AND  hourly-employee-record; 
CATpT»iAyT-Y  IS  n um bet-o f- hour ly-employees ; 

CON'l'=’C'"I  VI""  Y I 'T  1 TO  ma  x-depa  rt men t -employe men t ; 
lEF  IVA"! 0*f ; 

ney- empl oyeo- process! nq  adds  connections  while 
term  i na*- im- e mnlovee- prccessinq  deletes  connections; 

Of’ cf”)''’ n "'Toi^  . 

*-his  relation  connects  an  hourly-emoloyee-record  for 
each  efunloyee  in  a depat^'raent  to  the  department- record 
^or  tha*’  department; 

KE  Y woRp  denartme  n*--  i nf  o rraa  tion ; 

FAIN"’AINFP  ilY  n en-oRt ploy ee- pr ocessi nq  AND 
terra  i na*- inq- e irployee- processing  /*  DSINO 
department  AND  emplovee-identif ication-number  •/; 
pi?cpnv  sT3LE-P'^onLE*'-D’^FINEP  1chn-pr  octor ; 
cp('po-"Y  department-heads,  department-secretaries; 

5FT->»?«»o  rompan  v-orq an izat ion-chart ; 
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*=00  FC'‘  -’n  plovpe-^ ppl  ication-  f orm , 

nlov  f>e-  tf»  rmi  na  t i on-f  orra  , 
Ip  par t men  t-em  ploy ee- list ; 
SYVCSYf'  lept-to-emp,  d-e; 


■» . 0 nponn  in d ILl^lFN T Sections 

A"  ?LE?1ENT  is  the  lowest  level  lata  oh-ject  that  can  be  defined 
to  describe  data,  "ecause  of  this  property,  an  ELEMENT  has  one 
or  mote  possible  data  values  associated  with  it,  whether  it  be 
alphabet ic,  numeric  or  otherwise.  In  many  instances  an  ELEMENT 
mav  be  ‘•ho'ioht  of  syrcnymously  with  "field**  or  "item." 

^'LEMENT  (ELE) ; 

(list  of  element  names) 

A ClPOfjp  represents  a collection  of  ELEMENTS  and/or  GROtlPS.  The 
use  of  r*’0'TPS  is  definitional  which  means  that  referencing  a 
particular  GPO’lP  by  its  name  is  eouiwalent  to  referencing  the 
individual  ELEMENTS  which  the  GPOriF  consists  of. 

GPOUP  (GF)  ; 

(list  of  qroup  names) 

GPOnpS  can  be  broken  down  into  smaller  GPOHPS  and  ELEMENTS,  but 
’^'LEEFNTS  cannot  b®  subdivided.  FI.FMENTS  may  ta)ce  on  values 
where  GFOgps  may  rot.  -ryie  value  of  a GPOtJP  is  defined  to  be 
equivalent  to  the  individual  values  of  the  ELEMENTS  within  the 
GROTP. 


l.g.l  System- St  r uct  u r e Statements  for  GF  PUPS  and  ELEMENT  S 

"'he  FUBEFf^N  r.-c5  i'"ep  icN  statement  specifies  those  SETS  which  are 
subsettea  based  on  the  data  values  in  the  GROUP  or  ELEMENT. 

EUBFE'*TTNG— GPT'''F**"'0N  (SSCN)  ; 

(list  of  set  names) 


’.G.?  £a ta^St ructure  statements  for  GROUPS  and  ELEMENTS 

The  rcN*"  D statement  is  used  to  relate  the  data  structure 
relationships  o**  Gfonps  and  ELEMENTS  to  ENTITIES,  INPUTS  and 
cuTpuTS.  fc,  mort  often  thought  to  be  part  of  some  Large 

unit  of  data  such  as  a logical  record,  input  form,  or  output 
renor*,  which  can  h®  represented  by  the  ENTITY,  INPUT  and 
OU'npul,  respectively. 

CON^AINFr  fc-"'P)  . 

(list  of  qroup,  entity, 
input  and  output  names) 
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r^-jourx:  ani  may  b<a  defined  to  be  CONTAINED  in  sone 

larcier  Ol^oun. 

The  Crv^TS'^S  r?^atemer.t  is  used  to  specify  those  lower  level 
OROKPE  and  EIE^S-VT?  a OPO'/P  may  consist  of.  By  definition  of 
"^LEJIFN- an  '•LE''"N"  cannot  CONSTPT  of  any  other  data  objects. 
The  CCNSIS""*;  s’-atemert  only  specifies  the  data  in  the  GPOUP  and 
implies  no’-hino  about  its  format, 

CONSIE-'J  (CSTS) ; 

(list  of  qroup  and  element  names,  optionally 
preceded  by  system  parameters) 

" comcle^’e  problem  statement  should  have  all  GROUPS  broken  down 
to  smaller  OPOORS  and/or  FLErENTS. 

The  A??ocT.l'"r.D  statemen*-  specifies  those  DELATIONS  that  the 
cponrs  or  are  associated  with.  This  implies  that  the 

intoriration  in  ♦■he  GFOnp  or  ^LE!1ENT  is  in  neither  of  the 
'NTITTE?  the  R'^LA'^ror  is  PF'^WEEN. 

ASSOcTAT'='D  ; 

(list  of  relation  names) 

"ha  TrFKTT''TF<^  statement  specifies  those  ENTITIES  for  which  the 
or  ELEN’^'U'"  is  used  as  an  identification  key.  This  implies 
♦•hat  ♦•he  nossible  values  of  the  GFCUF  or  ELEMENT  are  all  unique. 
®or  example,  th^  ’^LENEN'^'  which  represents  social  security  number 
in  an  employee  record  miqht  b®  used  as  an  identifier. 

ID’^N'^'IFIFS  (ICS)  ; 

(lis»-  of  enti't-y  names) 

s qtqijp  or  EL'”'EN'"  may  identify  any  number  of  ENTITIES. 


’.b.l  PLia^Deriy  at  ion  ‘Statement  s f cc  GRO  OPS  anj  ELEMENTS 

•^h®  ISFD  s'-a^-emont  specifies  ♦■hose  F^OCESSES  which  use  the 
information  in  rhe  r.POMP  or  ELEMENT. 

USED ; 

(list  of  process  names) 

"his  ffatement  implies  (in  the  case  of  a GROUP)  that  at  lee^t 
one  piece  of  data  in  th“  GROUP  is  beinq  UFED. 

specify  the  manner  in  which  th®  GROUP  is  USED  more  precisely, 
♦■he  nfpTVF  or  udea"''  clause  may  be  used  in  conjunction  with  the 
E'ED  statement. 
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nSED  PY  _ 

(list  of  process  names) 

TO  OFFTVE  (PPY) 

(list  of  element,  qroup,  entity, 
set  and  output  names) 

or  'Ism  hv  a PPocE'^S  to  UPPATE  data: 

'ir?r  PY 

(list  of  process  names) 


"’O  npp)V"’w  (fJPO) ; 

(list  of  element,  group,  entity, 
and  set  names) 

"he  PPPIVED  statement  specifies  those  PPOCESSES  that  derived 
some  information  presented  in  th®  gPOUP  or  ELEMENT, 

PERTVpn  (D”VP)  ; 

(list  of  process  names) 

"his  stangmofit  implies  (in  the  case  cf  a GPOtfP)  that  at  least 
one  piece  of  data  (oro"”  or  FLFMENT)  in  the  GPOnP  is  DERIVEH. 

"o  specify  more  precisely  the  manner  in  which  the  GROUP  or 

is  der’v«d,  the  nsjNo  clause  may  he  used  in  conjunction 

with  the  DEPIVP  statement, 

pwoTynn  PY  (PPVD)  _ _ 

(list  of  process  names) 

fTcryc  ; 

(list  of  element,  group,  entity, 
set  input  ramas) 

"he  MPPiTEr  s*-a*-emert  sperifies  those  PPOCESSES  that  modify  some 
information  pr-esnn’-e't  in  the  GPCUP  or  ELEMENT. 

npOATpn  (f»pnPi ; 

(list  of  process  names) 

"his  statement  implies  (in  the  case  cf  a G^OUP)  that  at  least 
one  Piece  of  data  (TPOPP  or  ELEMENT)  in  the  GROUP  is  UPDATED. 

"o  specify  more  precisely  the  manner  in  which  the  GROUP  or 
'‘LEMen'"  is  updated,  the  ripinc  clause  may  be  used  in  conjunction 
with  the  gePA^FD  s* a ‘•emen t . 

UPPA^Tn  PY  (PPPP)  

(list  of  process  names) 


UEING 

(]  is*"  of  element,  group,  entity, 
set  or  input  names) 
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'?v«rv  G»:OUP  ’LErTN'"  (’efinp(^  should  be  USED,  DERIVED  or 

noDA'^pn  by  at  leas*-  one  PPncESS. 

The  CLA  S ST'=’TC  A7T0K  of  a GROUP  or  ELEMENT  may  be  specified  with 
♦■h**  CIASSIFICA'^TON  statement: 

Cl  ASSIEICA'^in*! ; 

(list  of  classification  names,  each 
optionally  followed  by  a level  number) 

Any  PFOC'’SSE.S  or  P^DCESSOPS  that  use  the  GROUP  or  ELEMENT  must 
have  SECUR'^rY-ACCFS'^- EIGHTS  that  match  the  classification  of  tha 
GROUP  or 


?.P.4  System-Size  121  ELEMENTS 

"'he  VALUE  s* a t-=‘men*-  is  used  to  define  numeric  values  an  ELEMENT 
may  have.  A GROUP  cannot  have  a VALUE  directly  associated  with 
it.  The  VALUE  sta*-ement  mav  only  specify  numeric  values  and 
does  not  imnly  any*-hinq  about  storage  format,  etc.  The 

and  0 ESC’’ T p'"ION  statement  should  be  used  to  present 
this  *-vne  of  irforma*ion  as  well  as  to  specify  character  values. 

VALUE  (VAL) ; 

(integer  value) 

Onlv  DOS i*! VO  in  toner  values  may  be  specified.  Decimal  numbers, 
nega*-ivo  numbers,  «tc.  are  not  acceptable. 

A ranoe  of  values  may  also  be  specified. 

VALUE'’  (VAT.)  TH^n ; 

(minimum  value)  (maximum  value) 

Anain,  the  value's  must  bo  positive  integers.  POSINF  and  NEGINP 
may  bo  usoi  »-o  roproront  positive  and  negative  infinity, 
respoc* i vely . 

Onlv  one  value  statomert,  of  oi*-her  of  the  forms,  may  be  given 
*-o  describe  a oarticular  ELEMENT. 

T.'^.E  Pro  doc -»•-!*  a nag  omen*-  Ft  a t ements  for  GROUPS  md  E)i.gHE  NTS 

-h’  '’FSPCHF’' PLE- P^OBI  EM-nEFlN3P  Statement  may  be  used  in  this 
Section.  Dosorip*lon  and  syntax  of  this  statement  are  given  in 
section  1.2. 

■*.0.*^  Systom-ppoper*  je.e  Ftat  emmts  for  GROUPS  and  ELEf)ENTS 

The  SYHOMyv?,  PTSCR' P"'I0K,  SFS-MEMC,  KEYWORDS,  ATTRIBUTE, 

ASSFET,  FE''URI'"Y,  FOPRCT  and  TRACE-KEY  statements  may  be  used  in 
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♦■hiF  St^rtion.  Uescr i ot ion  and  syn':ax  of  these  stateaents  are 
qiven  in  section  3.2. 

I.-'O  ifCCZSS  ^SGlion 

The  is  a sefl  to  define  the  function,  or  functions  of  the 

tane'-  svs'-eni.  A*-  *:he  hiahest  level,  the  function  of  the  target 
svsten  iray  be  defined  as  a sinqle  PROCESS.  This  PROCESS,  could 
in  turn,  be  broken  down  into  more  detailed  PROCESSES.  It  is  thi 
task  of  the  PROCESS  to  reference  and  manipulate  data  in  the 
tarnet  svstam. 

PROCESS  (PPC) ; 

(list  of  process  names) 


l^stem-now  ?iatemerts  for  PPOCESSES 

"“h^  PFC’'I\r=’S  statement  is  used  to  specify  that  the  PROCESS 
accepts  information  (INPUTS)  from  outside  the  target  system. 

»ECFIvrS  (OCV5) ; 

(list  of  input  names) 

"his  statement  onlv  specifies  that  the  INPUTS  are  accepted  by 
th?  FR0CE5’?  and  does  no*-  imply  that  the  information  in  the 
INn'i-c  are  USED  or  how  i '•  is  USED  by  the  PROCESS. 

"■h«  nFNEnA''FS  stat^men'-  is  used  to  specify  that  the  PROCESS 
produces  information  (OUTPUTS)  for  use  outside  the  target 
s vs*-  em . 

r.EN®‘vAT^s  (qrNS) ; 

(list  ou'^pu*-  names) 

"•'is  sta*-ement  only  specifies  that  the  oUToriTS  are  distributed 
by  the  rP<^C-ss,  and  does  not  imply  that  the  information  in  the 
on"otjmr^  is  r)F'»IV3b  by  tbe  PROCESS. 

these  statements  imnly  that  some  Physical  processing  or 
translation  mav  bo  necessary.  The  RECEIVES  statement  means  that 
the  physical  m£»d  ia  containinq  data  must  be  accommodated, 
'‘imilarlv,  the  oENf'>AT*'S  statement  means  that  data  must  be 
recorded  in  whatever  medium  has  been  chosen. 

3.'’C  .2  ^ys»ew-‘^t.  ciict  uro  Statements  fo£  PROCESS ES 

A OFOCESS  mav  be  part  o^  one,  and  only  one,  larger  PROCESS,  and 
it  may  hav»»  anv  number  of  subparts  that  ar®  also  PPOCESSES. 

t*A«T ; 

(process  name) 
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'J'TBPiFTS  (SHR?) ; 

(list,  of  orocess  names) 

■"h'^so  si- atom en'-s  opcmit  orqanization  functions  and  proqramminq 
s'-ruc'-ures  to  b®  defined  for  th®  problem  statement, 

"ho  n'^TlI7?D  and  qTIII7ES  statements  are  used  to  specify  that  a 
PROCFSS  renresents  a function  used  by  several  other  PROCESSES, 
refinition  of  UTILIZED  implies  that  the  PROCESS  is  common  to 
more  than  one  other  PROCESS.  If  not,  the  PROCESS  should  be 
■^ofined  as  a SUBPA®?. 

nTIITZEP  (n^LP) ; 

(1 ist  of  process  names) 

'IT^LIZ^S  ('ICL") ; 

(list  of  process  names) 

A qiven  FROCFS'^  mav  have  any  number  of  SUBPARTS  and  UTILIZE  any 
number  of  other  ?Poc  sere;  ^ p PROCESS  may  be  a StJBPABT  of  only 
one  other  PROCESS,  btit  he  briLIZEP  by  any  number  of  PROCESSES. 


I.IP.R  rata-  Per  i ya»  i on  Si-atements  for  PROCESSES 

""ho  rise's  stai-emer*-  .snecifief;  those  SETS,  INPUTS,  ENTITIES, 
^conps  ani  from  which  some  information  is  talcen  and 

used  bv  i-he  nnnrT.sr  to  perf-ar®  its  designated  function. 

TTC^S 

(lisi-  oi;  set,  input,  entity,  qroup  and  element  names) 

■'"n  i-he  case  wh^re  SFT,  INPUT,  ENTITY  or  GROUP  names  are  given, 
this  statemeni-  implies  i-hat  at  least  one  EL7EENT  within  these 
are  US^'P  hv  he  PROC’=’.''S. 

''’o  srecify  the  manner  in  which  the  PROCESS  nSES  the  data  more 
oreciselv,  the  nSTIVE  or  UPDATE  clause  may  be  used  in 
conlunction  with  the  [tSES  statement. 

O'"  ES 

(list  of  set,  inpul-,  entity,  qroup  and  element  names) 

"0  DTP  IV'" ; 

(list  of  set,  output,  entity, 
qrouD  an-i  element  names) 

f|r  t»c 

(list  of  sat,  input,  entity,  group  and  element  names) 

TP  PPCAT" ; 

(lis*-  of  set,  entity, 
group  and  element  names) 
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■"hf  UEPIVES  statamept  specifies  those  SETS,  OUTPUTS,  ENTITIES, 
OPnups  ar.'l  ELEMEN'^s  for  which  some  information  is  derived  by  the 
PROCESS  to  perform  its  desiqnated  function. 

DE'»TVFS  (Ucve-) ; 

(list  of  set,  output,  entity, 
qroup  and  element  names) 

’■p,  '■he  case  where  OUTPUT,  ENTITY  and  CROUP  names  are  given, 

this  statement  implies  that  at  least  one  ELEMENT  within  these 
are  nEPTVEU  hv  the  P^OC^SS. 

’’"o  speci  fv  ►he  manner  in  which  the  PROCESS  DERIVES  the  data  mora 
precisely,  ►he  USIMC  clause  may  be  used  in  coniunction  with  the 
OEBIVE*^  Statement. 

DE'JIWS  (DO  VS) 

(list  of  set,  output,  entity, 
eroup  and  element  names) 


USINC ; 

( 1 ist  of  set , inout , entity, 
qro'irt  and  element  names) 

”he  tJPDATE*^  statement  specifi'=s  those  SETS,  ENTITIES,  GROUPS  and 
ELEM'^NTS  for  which  some  information  is  updated  by  the  PROCESS  in 
performing  its  designated  function. 

UPDATES  (UODS) ; 

(list  of  set,  entity, 
group  and  element  names) 

►n  the  casf'  where  SFT,  and  GROUP  names  are  given,  this 

statement  imnlies  ►hat  least  one  ELEMENT  within  these  are 
unofT-pp  hy  PROCESS. 

To  speci  ty  f-he  manner  in  which  the  P'JOCESS  UPDATES  the  data  more 
precisely,  ►he  ustkg  clause  may  he  used  in  conjunction  with  the 
UPDA-E'^  Statement. 

npo^TES  (UPDS) 

(list  of  se* , entity, 
group  and  element  names) 


USING ; 

(list  of  sat,  inpu*,  entity, 
nronp  and  element  names) 

""he  MATETM'IS  s^at^ment  specifies  those  RELATIONS  or 
~’tBSETTING-SFI'^''ETnN  which  are  maintained  by  the  PROCESS. 
Maintenance  of  RELATIONS  normally  involves  addition  and  deletion 
of  ccnnections  between  ’='NTITIE£  whereas  maintenance  of 
srfDS  F— ing-CRI"''''’ION  deals  with  placement  of  '►NTITIES,  INPUTS 
and  OUTPUT"^  in  proper  S'=’TS  according  to  the  values  of  the 
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and  tpO'IP*^  contained  within  those  desiqnated  as 
'^iinS’=‘T'TTVG-CFr"'PPrON  names. 

I1ATN'’^TNS  (rrvS)  ; 

(list  of  relation  and 
subsettinq  criterion  names) 

py^rv  PFOCPSP  shovild  he  defined  to  interact  with  data  in  some 
manner  (PPOTVF'^,  US’^S,  'JPDATFS  or  MAINTAINS). 

""he  PRCrSDnPE  stat^'ment  is  used  •‘o  specify  an  algorithm  of  the 
function  of  the  ppnrFFS.  '"he  PPCCEDOPE  statement  is  a comment 
entrv  statement  thus  allowing  any  form  of  procedure 
specification  to  be  given  such  as  decision  tables,  actual 
orogram  co^e,  narrative  format,  etc. 

ongcpngp*'  (ppc'')  ; 


(comment  entry) 

'•very  ppncrss  ^hat  loes  rot  have  SUBPAPT?  or  does  not  OTILIZE 
any  ether  PprCFSppc;  5hould  have  a rPCCFDfJFE  statement  that 
soecifies,  in  sufticiert  derail  for  implementation,  the  rules 
for  carrying  ou*-  its  f\inction. 

"he  FFCnPTTy-ACCFSP- FTGHT.F  of  a PFOCESF  ray  be  specified  with 
«-he  SECUPT^Y- ACC  PIGH'^F  statement: 


FFCn  PT'"Y- ACC  FGP- RIGHT  F ; 

(list  of  classification  names, 
each  optionally  followed 
by  a level  number) 

s nt»oc’='*'S  ^ha*-  uses,  derives  or  updates  data  must  have 
«:t'crTBT-y_;cCF<=;F- '7TGMTF  that  match  the  classification  of  the 
data  . 


3.1 ''.4  Fvstem-Fire  Ft  gtement  s for  PROCESSFS 

"he  happF'ig  statement  is  used  to  specify  the  frequency  of  a 
"FOCIS*^  in  a eiven  •■ime  interval. 


HAPPENS  (HAP) 

(sy  St  om 

pyery  oepcpss  should 
associated  with  it. 


TIMFF-PEP  (TIMP) 

oarameter)  (internal  name) 

have  one,  and  only  one,  HAPPENS  statement 


F Ystem-OYnamics  statements  tor  PROCESSES 
"he  TPIGGEPFD,  ? E”"!  N A''Fr  and  TNTFPPOPTEn  statements  are  used  to 
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SD^^cify  ♦•hose  '=‘VEK’’S  , INPUTS,  P^CCtSSES  and  CONDITIONS  that 
af^'^ct  the  i nit  iali7  ation  of  prpcessinq,  or  the  halting  of 
processing. 

'•’’icGfprn  uY  

(list  of  oyent  , innut  and/or  process  naaes) 

TPTCCFRFD  WHEN  (TPGP) BECOMES  TRUE  (T) ; 

(condition  name) 

T-nrCGFriFD  WHEN  (TFCD) BECOMES  FALSE  (P)  ; 

(condition  name) 

-EPYINATED  BY  ("'PED) ; 

(list  of  event,  input  and/or  process  names) 

TER'’INA"'ED  W!!EN  (TFYr) BECOMES  IPOE  (T)  ; 

(condition  name) 

'♦'ER*  INATF'i  WUs-N  (TEMP) BECOMES  FALSE  (F)  ; 

(condition  name) 

TN-pcpUPTED  BY  (IN?-') ; 

(list  of  eyent,  input  and/or  process  names) 

-.jTJ-j:  pnpTFP  UH^’N  (INTD) BECOMES  TRUE  (T)  ; 

(coniition  name) 

TMTrcpgp-EP  WHEN  C^N'^D) BECCES  FALSE  (F)  ; 

(condition  name) 

PR'^CESSFS  may  also  I'PIOGF'’,  TERMINATE  and  INTERRUPT  other 
PROCESSES. 


"•nrgG^'FS  (TRCS) ; 

(list  of  process  names) 

TER'TNA''ES  (TTMS) ; 

(list  of  process  names) 

-v-fT-UPTS  (IN-S)  . 

(lis*-  of  process  names) 

PFOCESSFS  may  also  aenerate  EVENTS  and  set  values  of  CONDITIONS. 
\n  FVEHT  mav  he  generated  either  at  the  initiation  of  a PROCESS 
or  when  it  finishes. 

TNC’''‘'^‘'rTI-CA  USES  (INCC) ; 

(list  of  event  names) 

•♦■EN  FT  NAT  TON- CAMS  ES  ('♦‘EPC) ; 

(list  of  event  names) 

r AK*-S TRUE  (T)  ; 
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(list  Tf  coni^ition  names) 

FALSE  (F)  ; 

(list  of  condition  names) 

H ?Doc»'SS  mav  or  may  not  be  involved  in  any  system  dynamics 
relationships. 


l.1^.6  System^Archi^  ecture  Statements  for  PROCESS ES 

■"he  PFPvp3'»«FD  statement  specifies  the  physical  PROCESSOR  (e.g., 
hardware  or  ona  ni^at  ional  unit)  which  performs  the  functions 
described  by  th^  ’’POCFSS. 

nPDPCFMFU  (ppmru  ; 

(name  of  processor) 

Pv=‘rv  cPoc^SS  should  be  PEpfopmFD  by  some  PROCESSOR. 

""he  ?ESf'bpCF-U''AOF  sta»-eraent  indicates  resource  consumption 
associated  wi*h  the  FFOCFSS. 

PSSCnpcF-USAGE  ( PU)  FOR ; 

(system  parameter)  (name  of  resource- 


usage-  oar  ame^  e r) 


■’.I').?  Project- Management  Statements  for  PROCESSES 

"•he  P'=’SrONsinLF- PpnpLEF-rZFINFR  statement  may  be  used  in  this 
Section.  Pescrintion  and  syntax  of  this  statement  are  given  in 
sec<- ion  3.2. 

R.lj.P  Sv3»em-Prop^r  ty  Statemen  »s  for  PROCESSES 

"•he  SYMNymS,  OESC”!  PTTOK,  SEE-MEMO,  KFYHOHDS,  ATTRIBUTE, 

ASSvpt,  SECUFI-y,  FOnpcF  and  TFACE-KEY  statements  may  be  used  in 
this  Section.  Pescrirtion  and  syntax  of  these  statements  are 
given  in  section  3.2. 


a.ti  UJXIPiii;  f 2511211 

An  TV'^FFVAL  is  used  to  define  a segment  of  time.  A week  or  day 
are  simple  examnles  of  INTERVALS. 

tvtfpvAL  (IN'") ; 

(list  of  interval  names) 

■^t  is  impor^-ant  to  note  that  unless  defined  as  a SYNONYM,  WEEKS 
is  »'ot  the  same  as  w^'FK.  In  mos^-  cases,  it  is  desirable  that 
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both  name<=  renresent  the  same  interval. 


■’.■’1.1  Fvstew-St  ruct  ure  5 tat  ements  for  I NTFIR V ALS 

’"h'^  CONS'^STS  s^-atemert  specifies  the  smaller  INTEBVALS  that  the 
TV^E^VAT  can  be  broken  down  to. 

nNEIS""?  (CET?)  ; 

(list  of  interval  names,  each 
ODtionally  preceded  by 
a system  parameter) 

"■he  S YET  2M-P  A ^AM  should  be  specified  to  make  the 

relationshio  between  intervals  meaningful.  It  makes  little 
sense  to  sav  *hat  a year  consists  of  weeks  without  the 
ouan  t ita  ive  nroperty. 


1.11.2  Project- ’Management  Statemen  ts  for  INTERVALS 

-he  F'SncNsni,?- ppoBLi'M-DEFINEP  statement  may  be  used  in  this 
Sect  ion.  description  and  syntax  for  this  statement  are  given  in 
section  3.2. 

1.11  . System-Proper t ies  ^a^emen t^s  for  TNTE P VALS 

EyvonYM,  dtscfiption,  sef-xemc,  keywcfds,  attribute,  assert, 
'^'■TP’^ITY,  30T’9t?  and  T-pACE-KEY  statements  may  be  used  in  this 
3oc*-icn.  Oescriotion  and  syntax  of  these  statements  are  given 
in  section  ’ . 2. 

■*.12  CONpi"’IOM  <^ec*-  i on 

A m'C'jjcj-tqij  designates  some  situation  that  the  problem  definer 
wants  M-o  identify  because  it  influences  the  requirements  for  the 
system. 

CONPTTICN  (COND)  ; 

(list  of  condition  names) 

the  first  Qt  hhe  month  may  represent  some  CONDITION  for  which 
acticr  of  the  target  svstem  would  cccur  depending  on  the  state 
of  the  CCNdTTTON  . 

■*.12.1  E vst  em-Dv  nami  cs  Statements  for  CO  NDIT IQN5 

""he  TRUE  WHTL^  and  '‘AL'^E  WHILE  statements  specify  those 
situations  when  the  cONDItinn  is  in  the  TRUE  state,  or  in  the 
’'ALSE  state,  respectively.  This  information  is  presented  in  a 
comment  entrv  t^ormat. 
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T^UE  WHITE; 


(comment  entry) 


"•ALSE  WI'TL'^; 


(comment  entry) 

’’very  COKT)ITION  shoul.l  have  a TRUE  WHILE  or  a FALSE  WHILE 
sta^-  emen  t . 

a crNDITT^N  can  be  set  by  a PROCESS,  an  EVENT  or  the  arrival  of 
an  •’NEUT. 

*'Ar)ET'’”’”RY  ; 

(list  of  processes,  events  and/or  inputs) 

‘•AD’’  FAI'^’’  DY ; 

(list  of  processes,  events  and/or  inputs) 


"he  charqe  in  state  of  a CTNEITION  may  also  affect  the 
nrocessinq  beirq  performed,  or  may  initiate  new  processinq. 


ppco 

(PECG) 

TF”” 

(?) 

TPIGGEFS  (TRGS) 

• 

f 

(list 

of 

process 

nanes) 

R’”"0*'TNG 

(P-CG) 

’’AT  E E 

(P) 

"FIGGEPS  (TRGS) 

(list 

of 

process 

na  nes) 

n r;r  p T V n 

(P^CG) 

("■) 

TEP.MINATFS  ( 

?RH3) 

• 

(list 

of 

process 

na  nes) 

’’’’COM  IMG 

(B^CG) 

’’ALE  E 

C') 

•’F,  PMINATFS 

(TPMS) 

(list  of  process 

nanes) 

FECf’MING 

(PECG) 

TRUE 

(?) 

TKTFPPnPTS  ( 

INTS) 

(list 

of 

process 

nanes) 

RECnilNG 

(PECG) 

FAT  E E 

(F) 

IN  TEP  P up  T F 

(INTS) 

. 

(list 

of 

process 

na  nes) 

■Fhe  chan 

in  statr  of  a 

condition  may  cause  an  EVEN?. 

RECOMING 

(PFCG) 

'TTjrjr 

(T) 

CAUSES  (CSS) 

• 

(list  of 

event  n an  es ) 

P^Cn  riNf^ 

(PECG) 

FALS  E 

(P) 

CAUSES  (CSS) 

• 

(list  of  event  names) 


A Ct'ND""'TON  should  interact  in  some  way  with  at  least  one  EVENT 
or  PFrc’‘'’S. 


pAF- 
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3.12.2  Project- Manage went  Statements  for  CONDITIONS 

""he  RFSPONSIPLr.- PFOPIEM-DEFTNEB  statement  may  he  used  in  this 
'Section.  De55cri  p':ion  and  syntax  of  '•his  statement  are  given  in 
section  3.2. 


’.12.3  Sys'-em-Propert  jes  Statements  for  CONDITIONS 

'^he  SYNONYMS,  P?  SC'’ I PTION  , SIE-MEMC,  KEYWORDS,  ATTRIBUTE, 

ASSERT,  ?ECURI''’Y,  SPnpcS  and  TFACF-KFY  statements  may  be  used  in 
i-his  Section.  Description  ar.1  syntax  of  these  statements  are 
given  in  section  3.?. 

’.13  EVENT  Section 

An  FVINT  defines  an  occurrence  cf  scmething  within  the  system. 
The  state  of  a CONCi'^ION,  initiation  of  a PROCESS,  etc.  may  be 
def i ned  as  EVENTS. 

EVENTS  (EV) ; 

(list  of  event  names) 

An  EVEN'"  occurs  at  a given  instant  in  time  and  is  used  in  the 
nnhlem  statement  to  relate  the  things  that  go  on  in  the  system 
with  time, 

’.13.1  S vs*-e  m-Dy  nami  cs  Statements  for  EVENTS 

An  ^VFv""  nay  be  cause!  by  a PROCESS  (either  on  inception  or  on 
termination),  a CONPITICK,  an  INPUT  or  another  EVENT. 

CA'TSEP  PY  (CSD)  ; 

(list  of  event  and/or  input  names) 

CAUS^r  WHEN  (C'^D)  BECOMES  '"RUE  (T)  ; 

(condition  name) 

CAUSEP  WHEN  (CSD) BECOMES  FALSE  ( P)  ; 

(condition  name) 

ON  IVCEFTION  (TNCP) ; 

(list  of  process  names) 

ON'’’EFMINATie*j(T''='°M)  ; 

(list  of  process  names) 

An  '■VFN*''  may  cause  ano'^her  EVENT  or  set  the  value  of  a 

CONDIiICN. 

CAUSES  (CSS) . 

(US'-  of  event  names) 
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•"AKES 

(EAK) 

TRUE  (T)  ; 

(1  is«- 

of 

condition  names) 

■'AKES 

("  AK) 

(list 

of 

condition  names) 

,_FALSE  (F); 

An  "V^NT  mav  processim,  or  init,iate  new  procesing. 

'^'’If^GEF?  ; 


(list  of  process  names) 


’"t'o  V ('’’P^S) 


(list  of  process  names) 


TN?EFFUP"'S 


(list  of  process  names) 

An  -VEV^  shoull  interact  wi^h  at  least  one  COKDITICN  or  PROCESF. 

■"ho  HAPP’^SF  statemept  specifies  the  freguency  of  the  EVENT  in 
the  target  system  for  a giver  tinie  interval. 

HA'^PEKS  (HAH)  TIMES-PEF  (TT’IP) ; 


(svs*-em  parameter)  (interval  name) 

Ev«ry  EVEN"  sho'il'’  have  one,  and  only  one,  HAPPENS  statement. 


■’.11.2  Proiec t^vanagement  ftatemen_ts  for  EVENTS 

'"h'^  P^SPON'^I PFOBT  EE-DEFIN  EP  statement  may  be  used  in  this 
Section,  description  and  syntax  of  this  statement  are  given  in 
s»ct  irn  3.2. 

3.13.3  Eystem-Prooer  t jes  Sta  taments  for  EVENTS 

The  SYNONY'*?,  SC^  T PTIOK , SEE-YEEC,  KEYWORDS,  ATTRIBUTE, 

ASSFFT,  '’EcriFITY,  SOURCE  and  ’:’RACF-KEY  statements  may  be  used  in 
this  Section,  Description  and  syntax  of  these  statements  are 
given  in  section  3.2. 

3.14  PPOCESEQd  ^SCtion 

R orocFFSnv  is  an  object  that  can  "Ferforir"  a PROCESS.  That  is, 
a opec’’‘^'’0?  is  an  "anert,"  such  as  a computer  system, 
organisational  unit,  or  person,  that  physically  acts  to  perform 
a PROCESS. 

ppp^'pccer?  (Ppc’l  ; 

(list  of  processor  names) 


■*.14.1  System-St  FU?*'  statements  for  PROCESSORS 
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A ^>FCCS'^SO?  rav  be  part  of  one,  and  only  one,  larger  PROCESSOR 
and  it  niav  hav“  anv  number  of  subparts  that  are  also  PROCESSOR 

"A»'" ; 

(processor  name) 

SMBPAFTS  (STEP)  ; 

(list  of  processor  names) 

■^.1<*.2  r a'ta  - D er  i V a»  i o n flal^wsnis  fcr  PFOCESSORS 

In  the  target  system,  PPOCFSSOF  may  have  the  right  to  access 
inforira'-ion  of  certain  classifications  and  categories. 

''ECUPI'^Y-ACCFSF  = PTr,H'’  (SAP) ; 

(list  of  classification  names 
optionally  followed  by 
classification  levels) 

’.14.?  System-Architecture  Statements  for  PROCESSOPS 

A PPOCESSO?  may  rnvstllF  P'^SOUPCES,  such  as  CPU-time,  elapsed 
time,  or  memory. 

COVS'tMES  (CtJS^) 

(name  of  resource) 

PA'^I 

(s  VS  tern- pa  ra  me  ter) 


(name  of  rcsou  rce-usage-parameter) 

A PFOCFSSO’=  is  th<=  ohiect,  group  or  oerson  that  performs  the 
functions  soecifiel  by  one  or  more  PROCESSES. 

PESFCFms  (PF‘'S) ; 

(list  of  process  names) 

A.IU.U  Prolect- Management  S ta  temor  t s for  PROCESSORS 

•T-ho  FF'^POV'?-:  UL’='- PPOPL^r-nF.FIMEF  statement  may  be  used  in  this 
sac*-icn.  Poscriotior  and  syntax  for  this  statement  are  given  in 
ion  ?.  ■>. 

[ 

I 

I ■’.14.'  $ Y St  e m-p  roper  ty  Statements  for  PPCCSSSOPS 

,,  'he  SYvrvYMF,  DSSCFI  t’TTON  , SSE-rEFC,  KEYHCRDS,  ATTRIBUTE, 

A^UEPT,  SECf'RITY,  PonPCF  and  •"PACF-KEY  statements  may  be  used  in 
this  Section,  description  and  syntax  for  these  statements  are 
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'Tivf>n  ir  ion 

■>.15  PE  sonnet 

A •>’='SCnFCE  i.c  i nq  '■hat  tho  physical  elements  of  the  tarqet 

system  consume  in  offler  to  carry  out  information  processing 
function  s . 

C^SC) ; 

(name  of  resource) 

S vs'- em- Architecture  Statements  for  PES 0UPC5S 

A PESrrrrc^  nav  he  consumed,  or  used  up,  by  a PPOCE5SOP. 

rONS'!P'='P  (CNSD) 

(list  of  processor  names) 

^ATE PEP ; 

(system  oarameter)  (name  of  resource- 

usage- parameter) 

'Resource  usag^  must  he  measured  in  some  unit,  such  as 
milliseconds  or  feet. 

-EASnp^n  (vspp) ; 

(name  of  unit) 

■’.1*^.2  P rojec  t- 1 ana  gemen  t St  a temen  t s for  PESOUPpES 

'"he  RT.^- norm '‘'-PEFINER  Statement  nay  be  used  in  this 

Sec'-icn.  Description  and  syntax  for  this  statement  are  gi?en  in 
sect  ion  3.2. 


?.15.'>  'System- Proper  ' y ^tatgmen^  for  PESOUPCES 

■"he  SvvaNY.'IS  , n^'Ser-' PTION,  sfe-eeeo,  keywords,  attpibote, 

ASsr-p'T^  S-rnpr'"Y,  ST'PCE  and  TRACE-KEY  statements  may  be  used  in 
this  Section.  Description  and  syntax  for  these  statements  ace 
giyen  in  section  3.7. 


3.  IE  i'^enycE^rsiGE; rAfi^F^ER  Sect  ion 

a yEsrupep-ucaG^-PAP  A uE^EP  is  an  oh-ject  that  defines  a measure 
of  the  y^sonpc"''  usage  for  a PPOCEfS.  It  is  used  to  express 
resource  consumption  of  a PPCCESSOP  performing  a PROCESS 
independent  -^ha*-  PPOC^SSOP  performs  it. 

PSSOUFCE-MSAGP-°AyA”F,TEP  (PUP) 
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(name  of  rcsource- 
iisaqe-par  amef  er) 


’.If  r vs»»i\~Ai:chi  tcct.ure  Statements  for  pgSOUBCE-USAGE- 


A oarticular  value  for  HESOUPCS  usa.ge  may  be  associated  with  a 
qiven  Ppf'C’^'SS. 

F7S0UFCF-USAGg-PAFP''ETEP-VALUE  (FOFV) 

(system  parameter) 


f'OS ; 

(name  of  process) 

"5.  1*^.2  Proiec»- Management  St  a t emen  ts  for  PESOUPCE-US  AGE* 

P A M FTE  ? S 

'^he  SPSPONS"^  "LE- '’PPRLEM-DF'TVFR  s«-atnient  may  be  used  in  this 
Sec:*-icr.  Pescriptior.  and  syntax  for  this  statement  ate  given  in 
sect  ion  3,2. 


3.  If  .3  f vs;  2 Jin  ore  £1^  miSJSrls  for  PESOUPCE-USAGS-PAP  AWETERF 

■"he  SY^’OVY^;,c;,  PE  ?CFT  tTTo\ , FFE-F*^MO,  KEYWORDS,  ATTRIBUTE, 

ASSvtj*^  SrrgT,T*Y,  SOURCE  and  •’PACF-KEY  statements  may  be  used  in 
this  Section  . Pescription  and  syntax  for  these  statements  are 
given  in  section  3.2. 

3.17  S2cti2T 

li  UNI*^  is  used  to  measur'’  »ESOURCEF.  For  example,  possible 
UNITS  would  include  inches  and  kilowatt  hours. 

UNI” _ ; 

(nam“  of  uni*") 

2 . 1 • 1 Svs*-em-Arcti»  ec*ure  Statenients  for  UNITS 

A UNIT  must  be  associated  wi^h  the  RESOURCES  it  is  used  to 
meas  ure. 


MEASURES  (•‘^”31 

(list  of  resource  names) 


'^.^"’•2  Urojpclilllliag emen t statements  for  UNITS 

’’’he  •’FSPCVS"  PL"- P^OP’ Ef-nEFivEP  statement  may  he  used  in  this 
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Sec’-icn.  Df^scr i p*-ior  and  syntax  for  this  stateaent  are  given  in 
section  3.2. 


3.1  "^.3  System-Property  St  a»  eaen  ts  for  UN  ITS 

-he  SYN'3Ny»»S,  PESC’^’' rriON , '^EE-KEEC,  KFYNOPDS,  ATTRIBUTE, 

ASSERT,  SECU5T-Y,  SDURCB  and  TF ACE-KEY  statements  may  be  used  in 
♦•his  Section.  Description  and  syntax  for  these  statements  are 
qiven  in  section  3.2. 


T.1P  P3£PiEf;:;DfFINEf  Section 

-he  FpoP  lBK- N"’^  is  that  rerson  resoonsihle  for  one  or  more 
sections  of  the  tin  Problem  statement.  In  most  cases,  this  is 
♦he  oerson  who  orioinally  wrote  those  URL  statements. 

PBOBLET-DF’’TN’:'?  (PP) ; 

(list  of  problem  definer  names) 

3.‘’‘’.i  Proi2£;l;mil53£J2J3i  Statemerts  for  PPO BLEW- DEFINER 

-he  ♦esponstbLE  statement  is  used  to  specify  those  URL  sections 
for  which  the  p^  ODLE  ri-D  EETNE  »=  is  responsible. 

RERttcvET  PLE  (”???)  ; 

7Tist  of  namesf 

A nncRn=’r.-DF’='T'!E?  cannot  be  PESPONSTELE  ter  other 
P?OB  IFfi-  DEBT  wcRc  , 

A PFOPLEK-BEFINFP  should  be  »ESPCNSIELE  for  at  least  one  name. 

-he  faTLPOY  statement  specifies  an  address  for  the 

open LF*!- p EF7 N to  which  comments  or  nuestions  concerning  the 

problem  statement  ran  be  sent, 

•A^LneX  (BOr) ; 

(name  of  mailbox) 

A P'nRi.vf«_pFFTKr  have  only  one  MAILBOX. 


3.19.2  Ystqm-'>rop°rt  jes  Bta  tements  for  PFOBLEM-  pEP^NERS 

The  .CYWCvyes,  DESCFTITION,  SES-FErC,  KEYWORDS,  ATTRIBUTES, 
A9';’='R't,  secr,nt"y,  £oiipc’='  and  -PACF-KFY  statements  may  be  used  in 
this  Fection.  Descriphion  and  syntax  of  ♦hese  statements  are 
oiven  in.  section  3.2. 


3.19  «^ection 
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A '1F''0  is  1 narr^t-ive  description  which  applies  to  more  than  one 
name  in  the  problem  statement. 

memn  • 

(memo  name) 

""he  text  ot  ^he  I^FEO  should  he  put  in  the  DESCPIPTION  statement. 

1.10.''  Proloct-managonient  Statements  for  KEMOS 

■''he  '>'='SPOH'IHL^- PFOBI  FH-PEFIn::f  statement  may  be  used  is  this 
Section.  Description  and  syntax  of  this  statement  are  given  in 
sec'-icn  3.2. 


I 

i 


1 

i 

I 

I 

i 

t 

I 

i 

i 


L 


■’.I'*. 2 Svs»em-^roppr.tios  Statements  for  MFHOS 

The  ‘;YNONYtS,  Sr°  I PTT  ON  , KEYWOEPS,  ATTETB'ITES,  ASSERT, 

S *’Ct1 Y , SOtipc'^  and  TFACE-KEY  s'^atements  may  be  used  in  this 
Section.  Description  and  syntax  of  these  statements  are  given 
i n sec*-ion  3 , 2. 

""ho  AFPII'="^  statement  specifies  those  nPL  names  to  which  the 
wp'io  per'-ains. 

PreLIPS  (APP)  ; 

(1  ist  of  names) 

A F.EflC  cannot  Ao^I.Y  to  another  f*EHC  name. 

» TEHO  should  AP'^T.Y  tc  at  least  two  names.  Otherwise,  the 
informa'-ior  could  be  presented  in  the  DESCRIPTION  statement  for 
'■he  name. 


‘*.20  Tj3£  2££l.iSil 

’’’he  DFYT'jp  section  ir  used  to  specify  information  about  special 
'•ypos  of  names  tha'  do  not  have  their  own  H^L  sections. 

Th*^  format  of  the  DEFINE  section  is: 

prr>TVF  (T)EF)  name-type; 

(tJEL  names) 

where  the  name-type  may  be  one  of  the  following: 

A'^TPIFHTE  (A"’-"P)  - defines  a characteristic  or  mode  of 

the  target  system. 

AT'"'’ IPHTE-VALOE  (A"”"V)  - defines  a particular  value  for  an 

associated  ATTRIBUTE. 
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CLA SIT'TCA'^IO'I  (CL'')  - c:an  be  associated  with  data 

orocesses  and  processors. 


tr'-YWOFr  (K'’Y) 

rA^LPCX  (BOX) 


can  he  related  to  nanes  for 
retrieval  and  analysis  purposes. 

defines  an  address  for  a 
PPCPT  EF-DEFINEP. 


S^’CPFT'^Y  (‘^EC) 


defines  security  status  for  one  or 
more  UPL  names. 


5?0f»'’CF  (PFC)  - defines  a reference  for  additional 

information  related  to  objects 
heinq  described. 


VG-CFTTFPION’  (ESCN)  - 

defines  some  data  objects  whose 
value  is  used  as  the  criterion  for 
seqmentinq  a SET  of  data. 


<;  YS’’’ F**- r A ?,A  E TF  S (SYSP) 


"PACF-fFY  (■'K'’Y) 


defines  an  obiect  whose  value 
influences  the  size  of  particular 
aspects  of  the  system. 

can  be  used  to  relate  names  which 
exist  in  different  data-bases. 


P.PF.I  F vstem-Ft  rurt  ure  ^ for  the  D SflliS  Section 

gpqc i-TpioN  names  may  be  defined  to  apply  to  one  or 
more  5’^'“?  via  •■he  FU'^SETTING-CFITEFTCK  statement. 


cqns  yT-TNG-CPI''SPION  (SSCN)  

Yo  Other  name  •■ypes  in  the  DEFINE 
s*’a*’  emen  t . 


(list  of  set  names) 
section  may  use  this 


3. 2D. 7 nata- Derivation  statements  for  the  DBFIME  Section 

"'h®  M »INTAT‘I''’T)  r5tat=»mert  specifies  those  PROCESSES  that  maintain 
SriBS  ET"‘TNG-c»T’'*'PIO»’  for  oraanization  of  a SET. 

'•Alh’TATNFD  (CN'^’O) ; 

(list  of  process  names) 

raintenance  of  S'lnS'^TTING-CRITEFICN  involves  placement  of 

, T‘'P'r?  and  OMTPHTS  in  proper  SETS  according  to  the 
values  of  the  'sunsFIT  ING-CFITEP  ION  contained  within  them. 

No  other  name  tyn^'s  in  the  DEFTN’'  section  may  use  this 
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«5«-  om«r.  . 


5ys»  om-gj^A  y t atffipffnt  .s  jor  the  DF  FIN3  Section 

^n'1  AT'^’^IQ  IJTE-VA1UE3  may  be  defined  to  have  a 
VAL"^  or  ranqe  of  VAT.ijFP  associated  \(ith  them. 

■"h“  VATU’'  stat^nf'pt  is  used  to  define  i-he  nameric  values  a 
FYS"  Fr-F  A'lAr  F"’'’'  -"av  have. 


val'it:  (val) 


(inteqer  value) 


Only  fosirivp  in^-eqer  values  may  be  specified.  Decimal  numbers, 
neqative  numbers,  etc.,  are  not  acceptable. 


A ranqp  of  VALUE’S  may  also  be  specified. 


VAI.MES  (VAL)  THFU ; 

(mirimum  value)  (maximum  value) 

Aqain,  the  VALUES  must  be  positive  inteqers.  The  minimum  value 
mus'-  be  less  than  the  maximum  value.  POSINF  and  NEGINF  may  be 
used  ro  renresent  positive  and  neqative  infinity,  respectively. 

Only  cne  V'LUF  statement,  of  either  of  the  forms,  may  be  given 
to  d^scrib"  a particular  SYSTEK-PAFtilFTEF. 

Vo  other  name  typtir;  (n  the  DEeiNE  section  may  use  this 
St  at  emen  t . 


’.20.4  r ro  i c t^  'i  a na  q e me  n t Sta  temen  ts  for  the  DEFINE  Sect  ion 

•'he  fvspovstpl’'- '’TCPI EF-DEFINEP  statement  may  be  used  in  this 
Secticn.  Descripi-ion  and  syntax  for  these  statements  are  given 
1 n s action  ’ . 2. 


Sy  stam-PropF  r t ies  statement  s for  the  DEFINE  Section 

•’’he  SYN-nvv!»S^  DESCFTPITOV,  SEE-HEFO,  KEYWOPDS,  ATTFIBOTES, 
AS3’'’T,  SECU’’I’“Y,  SOi’Er?  and  TEACE-KEY  statements  may  be  used  in 
this  "pction  . 'iescription  and  syntax  of  these  statements  are 
giver  in  section  3.2. 

T*,«  Apei^’F  statement  may  be  used  for  FAILBOXES,  SECUPITIES  and 
'■nnFf'*'S  to  specify  the  uoi.  names  that  they  apply  to, 

APPLIES  (Ai’P) ; 

(list  of  names) 

*'xcep*'ions  are  hat  SFCUPITY  may  not  have  SFCUPITY,  and  SOUPCSS 
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may  net  have  a FOUPCF. 


3.21  The  OF  SI 'IF  A 7F  Section 


•^he  OFSinvA^F  'section  consists  of  one  statement  which  specifies 
tha^"  a qiven  name  is  to  b"  male  a 5YV0NYM  of  another  name. 

""his  facilitates  the  advantage  of  using  short  abbreviations  when 
referencing  a particular  oblect. 

D^’Sir.NA"'^  (DFSg) AS  A SYNONYM  (SYN); 

(a  name) 

A name  can  have  anv  number  of  SYNCNYHS,  but  a name  can  be  a 
synonym  for  onlv  one  other  name. 


Fo  other  s*atements  ar«  allowed  in  this  section. 


4.  STPAT^'gY  IF  OS’KP  HPL 

is  a very  flexible  and  comprehensive  lanauage.  Most 
situa*:ions  can  represented  or  expressed  in  OP L in  more  than 
one  way;  each  of  which  is  syntactically  correct.  However,  the 
di*'fprep*  renres-^nta  *•  ives  may  imply  different  semantics  which 
I may  or  irav  not  be  what  the  analyst  intended.  This  section 

describes  a number  of  situations  in  which  alternative  methods  of 
j expression  are  possible  and  outlines  the  implications  of 

I different  stra’-egies. 


I 4.1  Speej  fyi n g the  ” Pyst  em”  Boundary 

I In  MRI,  a 'ipA  data-base  contains  the  description  of  one  system. 

[ ’'ach  system  has  a boundary  and  the  system  description  may  be 

thought  of  as  consisting  of  two  parts: 


- the  specification  of  what  goes  on  inside  the  system. 

- the  specification  of  what  crosses  the  boundary. 

Altecnative  strategies  are  possible  in  the  order  in  whish  these 
parts  are  specified.  one  possibility  is  to  delineate  the 
boundary  firs*-.  "he  second  is  to  describe  the  "interior"  of  tha 
system  without  identifying  the  boundary. 


Specify  i ng  tjio  Boundary  First 

A firm  boundary  is  obtained  when  INTERFACES  are  defined  and 
♦•heic  conmun  i ca*  ion  with  the  system  is  specified  by  naming 
IFPHTS  and  ''Mypox.s,  it  is  assumed  here  that  INPUTS  enter  the 
system,  and  ng^pg^s  leave  the  system,  in  some  physical  form 
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containin^i  •’ata  valups.  The  constraint  in  URL  is  that  an  INPUT 
can  CPly  came  from  an  IN'^EP^’ACE  and  OUTPUTS  only  go  to  an 
■’’N'^E  Pf  AC  =■.  Inside  ♦:he  system,  a number  of  PROCESSES  may  he 
names,  each  one  of  which  uses  data  from  the  avallahle  sources  - 
INPUTS,  fN"'rTT’=‘S  or  SETS,  or  from  unsoecified  sources  - CROUPS 
an  1 FIEMENTS,  ♦•o  d^riv®  and  update  data,  A PROCESS  may  USE  data 
from  ary  of  these  sources  or  UEFIVED  from  any  PROCESS;  and 
similarly,  data  OFRIVEr  by  one  PROCESS  may  be  USED  by  any  number 
of  o«-her  P«50CESSES. 

One  benefit  of  ••his  approach  is  that  the  problem  statement  can 
bo  checked  for  comnl  e toness,  e.q.,  that  each  INPUT  is  GENERATED 
*'v  seme  ivcppetf”'  and  nECEIV^'O  tv  at  least  one  PROCESS  and  that 
each  OUTPUT  is  GEKFFATFD  bv  some  FPOCFSS  and  RECEIVED  by  at 
least  one  TNTZRpace.  Another  ten/^fit  is  that  the  description  of 
♦■he  INPUTS  and  OUTPUTS  can  bo  anreed  to  by  the  relevant 
’MTCRFACE. 

disadvantage  e f this  approach  is  that  an  INTERFACE  is  not  a 
PPOCESS  and  an  obdect  that  is  an  INPUT  to  the  system  cannot  also 
be  an  OUTPUT. 

Spec  if  Y ing  *•  he  I nterioc  ol  the  System  First 

In  somo  cases,  it  mav  he  desirable  to  dolav  specifying  the 
system  boundary  un^-il  the  inferior  of  the  system  has  been 
de-scribrd.  This  can  be  done  hv  not  identifying  any  INPUTS  and 
OUTPUTS,  but  instead,  dofir.ing  those  PROCESSES  that  USE  and 
P'PIVF  da^-a  and  dofinim  da^-a  in  terms  of  ENTITIES,  SETS,  GROUPS 
and  EIEK®’NTS,  What  would  ho  an  TN’^’ERFACF  in  the  previous  case, 
now  can  be  idon«-ifiod  as  a PFOC’^SS,  and  therefore,  the  obiect  in 
the  real  world  can  us®  data  from  any  sou rce- deri ved  data  which 
can  he  used  by  any  o’-hor  PROCESS, 

""ho  advantaao  of  •■his  approach  is  that  any  of  the  obiects,  e.g., 
ppocEES,  can  both  usf  data  and  PEFIV'  data  and  that  a given 
coll oct ion  of  data  identified  as  an  ENTITY  can  be  both  USED  by  a 
PPOCFSS  and  bo  dEFIVFP  bv  a PROCESS  (in  addition  of  course  to 
heir  q UPDATED)  . 


4 . 2 Assignment  of  Name  Types 

URL  reuuires  that  ^ach  name  (oblect)  used  in  the  system 
doscrip+^ion  be  of  a certain  type.  There  are  29  types  available 
of  which  2^  are  defined  by  their  own  sections  and  the  other  9 
are  define!  by  ♦■  he  PEeiN'’  section. 

■"he  assignment  of  a type  to  a name  is  crucial.  Statements  that 
can  be  made  about  an  cbiect  and  its  relationship  to  other 
ob1®c+s  are  limited  o those  available  in  the  object's  section. 
In  some  si':nations  •■(le  choice  of  a type  for  a particular  object 
is  clear;  in  o'-her  situations  there  may  be  several  legitimate 
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choices,  ?his  s«c*-ion  -liscusses  the  situation  in  which  there 
are  al^'ernat  i ves  , 


TVT'=‘PF  ACEg  VSESUS  PPQCEfSFS 

In  verv  general  ter’ns,  a FPOCESS  is  an  ob-ject  which  is  part  of 
tarcet  sys’-om,  an'i  which  operates  on  data  values  which  it 
«-o  DF^TV’  new  data  values!  The  P^JOCEfjS  can  also  UPDATE 
data,  ""he  data  which  is  used  by  a PROCESS  can  come  "from"  any 
other  PFOCFS*’,  and  the  data  which  is  DEHIVED  can  be  USED  by  any 
o*-her  rFCC’=’5F. 

’"n  contras’-,  an  P FACE  is  a unit  outside  the  boundary  of  the 

♦•arTet  svs’-em  which  can  produce  data  for  the  target  system 
(g^NEFATF  an  ’’VPUT)  and/or  receive  data  from  tho  target  system 
(“FCFIVF.  an  n-rnijT^  . 

An  object,  th-^reforo,  should  be  assigned  an  INTPPFACS  type  name 
onlv  if  it  interacts  with  the  target  system,  namely,  that  it 
will  either  FECFTVF  or  g’=’NERATE  data.  Otherwise,  the  ob  iect 
shotild  be  assigned  the  name  ♦•vpo  '•PPOCESS.” 


ii.t.2  INPUTS,  QU^PUl^  IlilllilS 

T\Dr'"-c^  Qr,tnrj-c  ^rici  FNTITTFs  are  types  of  obiects  which 
''con*-ain''  or  '*ca  rrv"  sets  or  collections  of  data  values. 
Conceptually , t^a  name  can  represent  both  the  "container"  or  tha 
collection  of  data  values  contained  in  that  container. 
Furthermore,  *•>•»  container  can  be  regarded  as  physical,  that  is, 
a card,  a ♦■ape,  a roccri  on  a disc,  etc.,  or  it  can  be  regarded 
as  a Icgical  construct  which  may  or  may  not  be  physically 
implemented  in  that  form. 

»n  obdect  sho'ili  b<^  designated  as  in  INPUT  if  what  is  to  be 
specifie*^  is  a container  with  data  values  coming  into  the  target 
system  from  oi*'sidp,  i,'^.,  from  an  TNTEFPACS. 

Another  -distinguishing  characteristic  of  INPUTS  and  OUTPUTS  is 
♦•hat  when  intornreta<a  ^ "containers"  of  data  values  they  are 
tomporarv  as  far  as  t^,^  target  svstom  is  concerned.  There  may 
bp  multiple  instances  of  the  particular  INPUT  coming  in,  but 
onc''  it  is  received  by  a PPOCF?s,  the  particular  instance 
disappears. 

♦’or  ficample: 


INPUT  time-card 

implies  that  the  system  will  receive  objects  of  type  INPUT  which 
are  called  timo-oard,  “h**  number  of  individual  ‘time-cards' 
wh^ch  arrive  is  specified  by  the  statements  such  as  HAPPENS. 
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R’milarly,  an  should  he  designated  an  OUTPUT  if  it  is  a 

"container"  of  data  values  and  if  it  is  specified  to  leave  the 
♦•araet  svs^em.  Again,  there  may  be  multiple  instances,  each  ona 
of  which  has  to  ho  GENFRAT’=’D  and  each  leaves  the  system.  Once 
individual  ins+-ances  of  the  OUTPUT  have  left  th®  target  system, 
♦•hey  are  not  considered  part  of,  or  accessible  to,  the  target 
syst  e» . 

"he  reasons  for  1 ist  i nqu ish i nq  INPUT55  and  OUTPUTS  from  ENTITIES 
and  OPOUPS  is  that  (1)  eventually  the  physical  medium  on  which 
rhey  anoear  and  their  representation  will  have  to  he  spacified, 
and  ('’)  ♦•he  source  and  destination  can  be  related  to  INTERFACES, 
and  Id)  time  and  volume  can  be  specified  for  INPUTS  and  OUTPUTS 
but  not  for  GROupr. 

♦In  rNH”Y  is  a "container"  of  data  value;  in  this  respect  it  is 
eguivalent  to  an  ’’NPUT  or  OUTou".  However,  it  differs  from 
r*’?UTS  and  0U''"PU'*’S  in  that  i i s internal  to  the  system  and  it 
nersists.  Therefore,  an  individual  instance  of  an  ENTITY  must 
he  creat^’d,  i.e.,  nr^TVEr. 

Again,  the  SNTT'’y  mav  be  a "logical"  collection  of  data  values 
or  i mav  h=»  a "physical"  collec*-ior.  When  it  is  designated  as 
a Physical  collectior,  it  will  prohably  he  implemented  as  a 
logical  record  or  physical  record  which  is  maintained  by  the 
svs*em  in  some  way. 

"h^refore,  an  ohiect  which  is  a collection  of  data  values  that 
is  in«-ernal  to  ♦■he  target  system  and  persists  in  the  system, 
should  be  dasiqna^’ed  an  ENTITY  rather  than  as  an  INPUT  or 
rjff"  PUT, 


U . ■> . 3 FNTITI<=’T  Versus  cogups 

An  ''V'TTTy  ic-  ^ logical  collection  of  data  values.  Data  values 
at-*  particular  ins^-ances  of  ELF'iFKTS  or  GROUPS.  The  data  values 
included  in  the  collection  are  specified  by  ♦■he  CONSISTS  of 
sta*empnt.  I G^otip  is  also  specified  as  CONSISTING  of  a number 
of  GROUPS  and/or  da^-a  ♦"LfMEV'T’s, 

"he  maior  listinc*ion  ho<-ween  ENTITIES  and  GROUPS  lies  in  that 
=‘N"I'^Y  is  a container  of  values  of  the  ELEMENTS  of  which  it 
COvyis'^E,  a gpoup,  on  the  other  hand,  is  merely  a notational 
convenience  for  namirg  a set  of  data  of  which  it  CONSISTS. 
Whenever  th®  analyst  finds  that  a number  of  data  ELEMENTS  appear 
in  a number  of  sitin^^ions  ♦■ogether,  he  can  simplify  his  writing 
time  and  analysis  ♦■ime  by  defining  the  collection  as  a GROUP. 

other  differences  hetviec.n  v^'^tties  and  GROUPS  are  the  following. 

1)  Groups  can  be  r'0»rATN-p  in  ENTITIES,  INPUTS  and  OUTPUTS, 
bu^  EVTI^T^S  canno*^. 


I USEF  PFOUIPEMENTS  LANGUAGE  MANUAL 


SO/r.ULTICS/URL  nSEP'S  »1A»JnAL 


167 


7)  FN’^msS  (\nA  INPfr.S  ani  OUTPUT?)  can  bp  CONTAINED  in  SETS, 
but  G’JOUPS  cannot. 

1)  EN^I'^IES  can  CONSTS'^  of  OPC'IPS  but  not  of  other  ENTITIES. 

fiprnps  can  CONSTS'^  of  other  GPCUPS,  but,  of  course,  not  of 
EN^ITTFS. 

>1)  GPCUPS  can  he  used  as  SUBSET-^ING-CP  ITER  I A of  SETS  and  to 
IPENTT’^Y  EN-^ITIES,  but  ENTITIES  cannot.  ENTITIES  can  he 
F'^LATED  via  RELATION  statements  and  have  ASSOCIATED  data 
consist inq  of  OFOUPS. 

S)  As  far  as  P?or'’SSES  are  concerned,  the  same  statements  that 
can  he  made  about  ENTITIES  can  also  be  made  about  saouPS, 
tho'iqh  when  ^he  ENTITY  is  us€*d  in  a statement,  the 
appropriate  statement  about  the  ELEMENTS  or  GROUPS 
Centatnec  in  k o entity  must  also  be  made  (See  Table  4.1). 

E)  noth  ENTI'"ITS  and  GECPPS  can  have  S YSTEM-PA  P AHETSRS 

associated  with  the  CONSISTS  statement.  In  addition,  the 
FN'^I'^Y  can  have  a C A FD  I'* » T I'^Y  and  VOTATILITY  statement 
while  a ct>pnp  cannot. 

"he  problem  d ’finer  should  specify  an  obdect  to  be  an  ENTITY 

when  he  wishes  to  refer  a number  of  ELEMENTS  as  a unit. 


1 '^election  of  Relationships 

All  rela  ♦■ion  shins  in  riPL  aro  precisely  defined  by  statements, 
"n  many  cas^^s,  onlv  on^  statement  will  be  leqitimate.  In  some 
cases,  however,  th^re  mav  be  a choice.  These  situations  are 
outlined  in  this  sf’ction. 


4.1.1  gFCEIVES/G’^N"F  Tl3  Versus  US  ES/UPD  AT’^S /PEP  I VSS 

1)  nErriV=’S/GENi^rA  Tre  can  only  refer  to  INPUTS /OUTPUTS 

whereas,  US ss/U PPA"ES/PE FI VFS  can  onlv  refer  to  "data." 

?>  USES  implies  ♦ha*-  ♦he  data  value  of  what  is  beinq  USED  must 
be  available. 

rPPATT.S  i'^'Dlies  that  the  data  value  must  be  CONTAINED  in  an 
ENTITY.  DEFI'/FS  implies  a value  is  computed. 

■»)  When  INPU"'-  ar^  USET , OUTPUT*;  are  DERIVED, 

SETS  are  qc  f’pn«"-rp  or  rFETVED, 

rvri^TES  ar-e  USEp,  rrPDA"FD  or  nE^IVEC 

this  implies  that  the  -lata  values  in  these  "containers"  of 
data  values  ar®  beinq  referred  to. 
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4)  Wh*:>n  ^’’OtlP?  ara  nS'^'D,  'JPDATFP  or  DERIVED  a»-  least  one 
element  in  th®  htjoup  is  referred  to. 

F)  "he  allowable  syntax  for  which  statements  can  affect  which 
obiects  is  shown  in  ""able  2.4.2.  The  meaning  of  the 
statements  is  shewn  in  Table  2.4.3. 

ACHIFVTVr.  flOOD  DOCMIENTATION 

Documentation  of  ♦•he  target  system,  of  its  interfaces  with  the 
organization  and  its  environment,  and  of  the  system  development 
nro-ject  is  used  for  different  purposes.  Figure  5.1  outlines 
so^e  characteristics  of  present  manual  documentation  and  some 
desirable  characteristics  that  are  achievable  with 
comnuter-aided  documentation . 

■"o  achieve  the  potential  benefits  of  computer-aided 
documentation  requires: 

- a formal  language  which  oermits  relationships  to  be  precisely 
defined . 

- a computer  orogram  which  provides  a method  for  enforcing 
correc*"  use  o*^  ♦■he  formal  language. 

- good  procedures  ♦■o  be  followed  by  the  analyst. 

The  lasf  of  fheso  is  imuortant  since  no  mafter  how  good  the 
language  and  fhe  computer  software,  the  benefits  will  never  be 
affained  iinless  fhe  tools  arc  used  properly. 

In  Section  5.1  the  c ha rac fe r i st ics  of  good  documentation  are 
describe'’  and  metho'^s  are  suggest  d hv  which  the  analyst  can 
achieve  •rhem  usi  no  nPI/(IFA.  Section  5.2  summarires  the  checks 
for  oreciseneas  and  consistency  which  are  performed  by  the 
'nalyzer.  Checks  which  the  analyst  can  perform  using  the 
oufnuts  available  from  the  Analyzer  are  described  in  Section 
*'.3. 

Thar  acf  er  is*-  j cs  of  3ood  Documentation 

’Isually,  the  analyrf  is  responsible  for  producing  documentation. 

"his  seefioa  ouflines  some  ma")or  attributes  of  good 
documentation  ani  indicates  how  an  analyst  may  use  DRL/URA  to 
achi eye  t h^m  . 

^ . 1 >'r  d ^r  s » an  i ahi  1 i ty 

"oci  men  * a*-i  0 n with  this  characteristic  is  in  an  easy-to-read 
'nrma*  and  is  nresented  at  a oeneral  enough  level  so  that 
r>^'-'<cns,  no  aa’-fer  what  fheir  background,  should  be  able  to  read 
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1 ccmproheni  ♦•he  matrerial  within. 

’’enor^s  can  nenerate-i  from  the  prohlen  statement  in  several 
commcn  format’s,  e.q.,  flow  rliaqrams,  matrices  and  at  different 
levels  of  detail,  ''or  example,  it  is  often  desirable  to 
initially  orecjont  hiqh  level  obiects  and  have  subsequent  reports 
nresent  mor“  and  more  detail  about  these  obiects  until 
everythinq  is  d-* -.cri bed  in  terms  of  their  lowest  level 
oonstituents  . t’he  analyst  can  choose  the  ordering  and  content 
of  the  reports. 


’’res  ent 
'lanual 

Uqcu  men  t at  ior. 

Hard  to  Understand 
A mbi quous 
tnronsistont 
’"n  complete 
■^nco  r rec*- 

difficult  ♦o  Ana  IvTia 
an  d Ev  aliiat  « 
f-tard  to  Modify 


Uesirable  Characteristics 
of  Computer-Aided 
J}2£12  3 °n  t ation 

Understandable 

Precis^ 

Consist  ent 

Complete 

Correct 

Computer-Aided  Analysis 
and  Evaluation 
Computer-Aided  Updatinq 


Fiqure  '^.1  Characteristics  of  Documentation 


. 1 . 2 Precisenes  s 

Documentation  with  this  quality  must  have  all  relevant 
♦•orminoloqv  explicitly  defin^l  so  that  information  presented 
cannot  bo  misinterpreted. 

A computer  i n ♦er pro" ed  lanquaoe  must  have  an  accurately  defined 
syntax.  “ res->rved  words  in  the  syntax  of  UPL  are  used  to 
describe  different  obiects  and  the  relationships  between  the 
obiects.  Definitions  of  all  reserved  words  allowed  in  the 
syntax  are  fix"'^  so  that  all  relationships  presented  in  the 
'^ocu ment  a^ion  (UFA  rf>corts)  are  exactly  th*^  same  as  those 
initially  specified  by  ♦■he  analyst  (i.e.,  there  can  only  be  one 
interpretation  of  the  information). 


D.  t . ? Consist -^nc v 

f'ocumon^-ation  which  is  "consistent"  presents  all  the  material  in 
proper  context  and  does  no^:  have  statements  that  are 
conflirtinq,  contradictory  or  i nco rs ist e nt . 

"^he  context  in  which  a particular  object  is  to  be  used  is 
defined  by  the  user  via  UPL  statements  which  will  be  stated  in 
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♦■ho  n»A  V'ar;'=».  Arv  attemntF;  to  use  the  previously  i ef  ined 

ohiert  in  a conflictim  context  will  result  in  an  error 
diaq nost  ic.  Thoreforo,  use  of  noA  ifaintains  consistency 
♦■hrouqhout  the  docuinenta^  ion  , 


'^.1.4  c>.  wplet  on°s5 

■"o  be  "comnle  to, '•  iocumon  vat  ion  must  nresen^-  the  material  in 
su'^ficient  detail  so  that  no  reference  to  outside  sources  is 
neo-iod  for  a thorouoh  nnderstandinq  of  tho  subject  matter. 

'!very  necessarv  niece  of  information  must  be  available  and  no 
relationshin  must  be  left  danqlinq. 

’I'»L  allows  a number  of  relationships  and  objects  to  be  defined 
to  describe  an  for  ma^- ion  Processing  System,  The  UPL 
statements  offered  provide  a thorough  outline  of  what  should  be 
incorporated  into  the  'documentation  of  an  TPS.  The  statements 
in  nPL  facilitate  t^e  enforcement  of  completeness. 


. d , 5 Correct  ness 

”o  be  "correct,'*  tKa  analyst  must  insure  that  all  relationships 
spacifie!  in  t^o  documentation  are  valid,  and  that  all 
information  recorded  is  true. 

Th“  syntax  rules  enforced  by  gpA  insures  that  all  relationships 
in  the  docum  enta  t ior  are  valid.  Though  it  is  impossible  to  know 
whether  t^e  in^'ormaticn  recorded  is  true  or  not,  many  of  the 
reports  available  can  present  the  information  in  a format  easy 
^or  thp  analyst  to  check  for  errors  (e.g.,  misspellings, 
incorrect  narrative  de.scr ipt ions,  etc.). 


'■.I.b  Analyzahility 

Documentation  which  is  analyvable  must  be  organived  in  such  a 
way  tha*'  arv  in<"ormation  not  explicitly  stated  in  it  must  be 
easily  derived  through  some  procedure. 

Since  all  UF I s‘-atpments  are  stored  in  a data-base,  all  data  is 
easily  accessed  and  can  be  presented  in  the  form  of  a nPA 
report.  tp  a -Edition,  any  new  developments  in  analyzing  the 
infofsation  (e.q.,  Cost/Penefit  Analysis,  etc.)  can  be 
incorporated  into  the  existing  dPA  package. 

*? . 1 . 7 Ease  o£  ''lo  dif  icat  ion 

Pocii  mont  ati  on  which  is  eqcjy  t^  modify  must  have  sufficient 
indexing  facilities  so  that  all  occurrences  of  a given  item  in 
the  documentation  may  be  referenced  if  and  when  a change  to  the 
item  is  regiiirei. 
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P<?causf>  thp  information  us^i  in  drrivim  URA  reports  is 
con'-ained  within  th=»  rjF®  data-basp,  any  modifications  to  the 
da'-a-hasp  will  hp  reflpcted  in  reports  produced  after  the 
chanqc.  MPA  offers  several  coniitiar.ds  to  modify  the  data-base. 
Anv  reports  qeneratp't  after  the  modifications  will  be 
up- 1 c-da  to. 


'^.2  Chocks  Carried  Out  by  tho  Anal  V2er 

*'or  the  most  part,  thp  characteristics  of  qood  documentation  can 
be  realived  when  the  documentation  is  qenerated  by 
computer-aided  means.  Preciseness,  consistency,  and  correctness 
are  all  checkad  by  the  »naly7er  as  new  information  is  added  to 
the  data-base  or  data  is  modified  in  it. 

MPA  can  produce  several  hundred  diaqnostic  and  error  messages. 
*’ach  is  id^ntifiod  bv  a number.  The  complete  list  is  given  in 
the  "Mser  Feauiremer.  t s Analyzer  User's  Manual”  in  numerical 
order  to  facilitate^  correction.  Mere  the  error  messages  are 
analyzed  in  terns  of  how  they  contribute  to  good  documentation. 


''.2.1  Checks  Related  to  P rec  i seness 

A considerable  portion  of  the  error  detection  facilities  in  the 
'nalyzor  are  used  to  check  th®  "preciseness"  of  new  MFL 
statements  being  added  to  the  data-base.  (This  is  done  each 
tim'^  I^-MPL  is  ini*-iated.)  The  Analyzer  must  check  that  the 
syntax  is  correct  and  that  the  user-defined  names  given  in  the 
npw  statements  are  consistent  with  names  already  in  the 
data-hase.  If  either  of  these  conditions  fail,  an  error 
diagnostic  must  be  generated  by  the  Analyzer  to  inform  the  user 
that  the  information  to  be  stored  in  the  data-hase  was  ambiguous 
or  inconsistent  with  th®  information  already  in  the  data-base. 

No  ambiguous  or  inconsistent  information  is  stored  in  the 
data -has  e. 

a)  Fynt^r  ’='rrors 

Erpakinq  anv  of  the  svntax  rules  of  MPL  will  cause  the 
Analyzer  to  goaprafp  one  cr  more  error  diagnostics, 

Typical  svntax  errors  are; 

- use  o^  illegal  characters. 

- misspelling  of  IjeA  reserved  words. 

- omission  of  srmi-colon  to  terminate  line. 

Table  S.1  j,  complete  list  of  diagnostics  produced 

when  a syntax  error  is  enccur. tered. 

h)  Incorrect  Use  nf  Names 
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is  verv  ii^portant  that  once  a namp  is  defined  and  has  an 
associated  name  tyne  alonq  with  it  (e.q,,  PROCESS  ar  SET), 
the  nano  can  only  he  used  in  the  context  in  which  it  was 
defined.  Therefore,  a name  defined  to  be  a PROCESS  cannot 
also  be  used  to  define  a of  data.  Likewise,  only 

those  relationships  specified  by  the  "User  Requirements 
lanquaqe,  Lamuaqe  Feferencp  Manual"  can  be  used  to  relate 
♦■o  obiects,  ^or  example,  a USES  relationship  between  two 
PROCESS  names  is  no*  allowed  and  any  attempt  to  specify 
this  would  cause  the  Analyrer  to  qenerate  the  diagnostic: 

MUST  UE  element,  GPOUP,  INPUT,  ENTITY  DR  SET 

Table  presents  a complete  list  of  the  errors  that  can 

be  encountered  when  incorrectly  using  names. 

^.2.2  Checks  Associated  wj* h Consistency 

As  u®!  s*a*emen*s  are  being  added  to  the  data-base,  the  Analyzer 
also  checks  *hat  the  new  relationships  being  specified  are 
consistent  with  *he  information  already  in  the  data-base.  In 
the  previous  section,  the  Analyzer  was  shown  to  check  that  once 
a name  was  defined  to  be  a aiver  name  type,  it  could  not  be  used 
ir  a conflicting  context  (i.e.,  as  a different  name  type).  The 
Analyzer  must  also  check  that  the  relationships  specified  for  a 
given  name  do  not  conflict.  Por  example,  if  an  ENTITY  was 
defined  to  have  a 3APDINALITY  of  it  would  be  illogical  to 

also  say  that  its  CAFCINALITY  is  The  Analyzer  will  detect 

these  types  ot  inconsistencies.  '^ho  Consistency  Error  Messages 
are  liste-’  in  ""able  5.2.  Table  5.U  presents  the  various 
inconsistencies  detpcted  by  the  Analyzer  according  to  name  type 
and  relationships  within  the  system  description. 
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^rror 

Number 

2 

'4 

r 

7 

I'"- 

1 1 

qo 

114 

■•IS 

■•10 

2''1 

221 

22h 

220 

201 

202 

2f^r, 


<1  nosi  ic 

nl’=:n  nam^  too  long 

NLEY  •'^OF'  NOT  '•O'INn  PEFOFE  EKD-OP-FILF 

EFPrF  OPENING  CATS  RASE  FOR  - 
NLEX  FNP-CF-riLZ  IN  MTDLE  OF  COMMENT 

SCAN  IT  LEGAL  CHAPACTEF  - IGNORED 

PFDnC'=’  NO  APPLICABLE  FROmCTTON  - SYNTAX  ERROR  - START 
SKIPPING 

S’-ACK  ILLEGAL  SYMBOL  PAIR  - SYNTAX  ERROR  - START 
SKIPPING 

CO'^ENP  END-OF-FILE  IN  CCMMFNT  ENTRY 

PWLIS"  SSCV  IS  ONLY  LEGAL  TYPE  IN  DEFINE  SECTION  WHICH 
CAN  3F  MATNtaTKEP 

VL^S"  ONLY  SINGLE  VAIUF  CP  RANGE  ALLOWED  - IGNORED 

OTHERS  VALPES  only  LEGAL  FOR  ELFMENT,  SYSPAR, 

OF  "TTSinilTE-VALnE 

CLPCA  PNNrH=  NOT  ALLOWED  IN  THIS  IMPLEMENTATION 

PLTST  N?EP  NO'^'  PART  Cp  FIEADFR 

ENLIST  CAN  NO"  HAVE  KEYWORD  FOP  KEYWORD 

FWLIST  CANNO':’  HAVF  SECUFITY  FOP  SECURITY 

PVL^ST  ^ANNCT  HAVE  SOUPCF  FOP  SOURCE 

RWLTST  SYNr'NY''S  ONLY  APPLIFD  TO  FIRST  NAME 

APPLFS  A'’PII’=-S  STATEMENT  ILLEGAL  WITH  THIS  NAME  TYPE 

7LLET  TTLFGAI  STATSFENT  IN  THIS  SECTION 


Table  5.1 

UPL  Syntax  Error  Messages 
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'=’rro  r 
'iiinihf  r 


2*= 

HEAD 

<5  1 

’'WT  IS- 

K1 

NLISTR 

1T2 

V L'!’  F I 2 

■’19 

CI.RC  A 

:o? 

ULIST 

DE'='N 

POR 

(^PTc;  Y>j 

2''U 

CUKCON 

RIR 

rP'^’N  U N 

211 

O-H  E R S 

21  A 

rTHP  p«: 

217 

n-HEPS 

210 

CLSEOA 

2’4 

OP-R  W 

23S 

Op’’!  ov 

RR'} 

OPTION 

24'' 

Hpr>L  r j! 

7(1  1 

APPLES 

RUB 

ARPI  ES 

247 

APPLES 

24  B 

AP"!  ES 

257 

ROHM’^L 

RFR 

ILLS- 

1 
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Piai]  noetic 

I'’VALin  HFAD’^P  S'^ATEMENT  - STATEMENTS 
WILL  BE  TTNOPED 

pp  supset’^inu-cpi'^epion  name 

*lA'«f  AL'^EADY  USEE  IK  DIF'^EPENT  CONTEXT 

».Mr  iiF’^ADY  USEE  IN  DIFFERENT  CONTEXT 

FIL''=  NOT  allowed  IN  THIS  I M^’LE  K ENT  ATIO  N 

NA-'F  PREVIOUSLY  USED  DIFFERENTLY  - ICMORED 

NA‘"^  ALREADY  USEF  IN  DIFFEPFNT  CONTEXT 

ofNEOT  PE  MADE  SYNONYM  - DIFFERENT  TYPES 

S^ACF  OVf.PPLOH  WHILE  WALKING  CONSISTS  STRUCTURE 

NO  NAMES  IN  DATA  FASE 

NAME  MUS"'  SE  ENTITY  NAME 

NAME  MUST  3E  ENTITY  NAME  BEFORE  VIA 

NAME  MUST  3E  RELATION  AFTER  VIA 

ETL’^=  NOT  ALLOWED  IN  THIS  IMPLEMENTATION 

NAi'’^  ALREADY  USED  IN  DIFFERENT  CONTEXT 

NAM’^  ALREADY  USED  IN  DIFFERENT  CONTEXT 

NAME  LIST  "'GO  LONG  - '’EST  IGNORED 

KEYWORD  CANNOT  APPLY  TO  KEYWORD 

MMLHOX  CAN  ONLY  APPLY  TC  PD 

SECUPI7V  CANNOT  APPLY  TO  SECURITY 

SOURCE  CANNOT  APPLY  TO  SOURCE 

CANNO"^  APPLY  "0  MEMO 
NAME  NO"-  IN  T)Xik  BASE  - 
VO  r URGENT  SECTION 


-able  5. 2 

URL  Name  Error  Messaqes 
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"rror 

N’liiher 

72 

1*7 

uu 

Cl 

c 1 
61 
6'' 

‘'1  = 

117 

I'l'' 

21  2 

71  ? 

7ia 

21'^ 

->iq 

-)C5 


diagnostic 

PWLTSl  PArr  ATTPinUTE  ALEEADY  RIVEN  WITH  DIFFERENT 
ATTFIdU'^F  VALUE 

or'ffps  CAPri'IALITY  ALPFACY  GIVEN  AS  SYSPAP 

OTHFPS  dlNAl  I'^Y  ALPFADY  GIVEN  AS  DIFFERENT  VALUE 

APPLE'S  SF70NO  EAILDOX  FCF  FD  ILLEGAL 
PWLTST  ALFFADY  PAPT  OF  SOMETHING  ELSE 
'’WLIS"  SFCCND  Pd  POP  "HIS  NAME  ILLEGAL 
FWLIST  ALFEADY  PART  OF  SOMETHING  ELSE 
VLIST  MIN  NOT  LESS  THAN  MAX  - IGNORED 
C''UT’’S  DI’'’='EKFN'“  VALU’^S  ALREADY  GIVEN 
SETSYN  ALPFADY  SYNONYM  FCF  SOMETHING  ELSE 
O'T'UEFS  '•'’^LATIO‘1  ALPSAFY  EXIS'^S  BETWEEN  TWO  OTHER 
NTITIES 

OTMEPS  CAN  only  ONF  CARDINALITY 

OT.,,2;rc  CONNECTIVITY  ALFFADY  GIVEN  FOR  THIS  RELATION 
PWT.TSl  ALPFADY  CONTAINS  WITH  DIFFERENT  SYSTEM 
“AdAEEi’E  P 

OTUEF?  PPLATION  ALRE»EY  EXISTS  BETWEEN  DIFFERENT 
Pfi-rTTY 

FNLTS"  CdMKPCTTON  ALPFADY  EXIST  WITH  DIFFERENT  VALUE 
OR  NAME 


Table  E.3 

UPL  Consistpncy  Frror  Messaqes 
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COVSISTFNCY  E&ROPS 
System  Hata  Data 


Flow 

Struc’-ur® 

S*-  ruoturp 

D'?ri  vati  on 

3 W5 

61,6  3 

ivnti  *! 

^=1,63 

0'17PLT 

61,63 

EVTI  •'Y 

212,218 

Tie  s 

212,218 

T'ROr  EfS 

^1,6? 

O^M'R 

2 c 

205 

2'“  5 

90,205 

? ys*"  “ m 

S i7° 

Sv  s t om 
''  yna  mics 

SystPm 

ProDorties 

Project 

Management 

62 

21'= 

62 

OfJ-"pi;T 

2'"= 

62 

U ■>  , U !i 

")  1 1 '>  1 F 

- - ' 

62 

'®‘N  TT  T Y 

43, 

21  3,2‘'4 

62 

a 3 ,U4 

2 t 3,2  14 

62 

GPO'»  F 

215 

62 

-L"" 

*•  I'',  •'  1? 

62 

npr,C='^5 

62 

y v’^F  tJ  VM, 

2 1 c 

62 

n p B 'I  ^ 7T  p 

2t  S,  15 

62 

r V T 

62 

C^VDITTG’I 

62 

COypTTT^N 

62 
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OTHEP  2^''^ 


PAP"" 


705  22,205  60,62,205 

?A3LE  •'.4 
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".1  Consis*- pncv  CSiBlSi “Ujss  Checks  Carried  nut  by  the 

Aral  V St 

At  seme  point  in  time  in  the  devolopraer. t of  the  problem 
sta emer  t , the  Aralvst  mav  want  to  check  its  state  of 
consistency  and/or  completeness.  The  Analyst  can  perform  these 
checks  by  inspection  of  yarions  reports  available  from  the 
Analyzer.  This  technique  is  possible  because  all  information 
specified  in  the  da*'a-base  can  be  presented  yia  one  or  more 
reports.  Since  the  Analyzer  has  checked  all  inputs  to  the 
da*:a-base  for  syntax  and  consistency  errors,  the  problem 
staromen*-  presented  is  always  in  a correct  state.  It  is  the 
role  rf  Analyst  to  determine  whether  it  is  totally 

"consistent"  or  "complete." 

■^able  f presents  a summary  of  all  consistency  and  completeness 
checks  <-o  be  carried  out  by  the  Analyst. 

""able  *^.6  presents  a summary  of  the  benefits  of  particular  URA 
reports  in  identifyinq  inconsistencies  and  incompleteness  in  the 
problem  statement. 
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I)  SYST’='.1 

a)  Ml  IN'r’='»i^»CES  should  GENERATE  some  INPUT,  PFCEIVE 
som"  QU'^'P^T,  or  be  PFSPONSIBLE  for  some  SET. 

b)  All  TNPn-"r  should  ho  GENEPATEb  by  at  least  one 

T .j'^r>r  . 

c)  All  'TNPnTS  should  be  FFCEIVED  by  at  least  one 
p pocr  ss . 

d)  All  O'J'^P'ITS  should  be  GENERATED  by  at  least  one 
OPOCESS. 

e)  All  OU''Pn"‘S  should  be  PECEIVED  by  at  least  one 

T N-rrp  FSC^  . 


■'ll  SYSTEM  STPriCTHPF 

a)  All  P30r=-SS':S  without-  SCBPAPTS  should  have 

h)  vi'-.h  SPSSE'^S  should  have  SUSS ETT  I NG- CR IT  ES  lA . 

c)  All  INPU”?  without  SIlBPAPTS  should  he  broken  down  via 
thoCGK.SISTS  statoinent. 

d)  All  OM-^P'IT?  without  SUBPAPTS  should  be  broken  down 
via  •’he  CCNSIETG  statement. 


al 

b) 

c) 

e) 

f) 
q) 


^ c"'c  ry'"'  UPE 

All  ETEiwpvTr  Should  be  available  from  an  INPUT  or 
from  a ’'NTT'^Y,  or  'DERIVED  by  some  PROCESS. 

All  S’"?  should  CONSIST  of  INPUTS,  OU'-pUTS  or 
rr  5:  ^ 

All  ’NTH  IBS  should  be  broken  down  via  the  CONSISTS 
s t a *^o"ir.n  f , 

All  T'JPU"?  should  be  broken  down  via  t-he  CONSISTS 
statomept-  if  there  are  no  SUBPARTS. 

All  OU"?U'^S  should  be  broken  down  via  the  CONSISTS 
sta'^e  men'-  if  there  are  no  SUSPAP'^S. 

All  FELATIONS  should  have  a BTTH’EN  statement. 

All  GPOtlPS  should  be  composed  of  ELEMENTS. 


"able  5.5a 

‘^ummarv  of  Completeness  Checks  to  be  made  by  Analyst 


-r  ticeT5  C PQUT0F*FIJ-TS  LANGUAGE  MANUAL 


•!  P0/MUL?IC3/L'PT  !]?«:;?»$  KAN  HAL 


ISO 


IV) 


A r'^f^IvaTZO” 

a)  All  i='L’^'''^NT‘?  shoul'l  h°  USED,  HPDATED  and/or  DEFTVED 
bv  a*  Ifa?*^  one  PPOCESE. 

b)  »ll  oR'^r'^rSE*?  rhoiild  acquire  information  by 

'’FC'IVTvq,  or  UPTATTNO. 

c)  All  oROC^SS”S  should  produce  information  by 
GPM^’-'ATINC;,  DEPIVING,  or  tlPDATING. 

d)  All  should  be  USEP,  UPDATED  or  DEPIVED  by  at 

leas*'  on®  FPOCEES. 

®)  All  should  have  a DFFIVATION  statement, 

f)  Ml  should  be  D3FT,  UPDATED  or  DERIVED, 

q)  All  ILEKENTE  within  an  INPUT  should  he  USED. 

h)  All  ^LEi“F*!Tf^  within  an  OUTPUT  should  he  DERIVED. 

i)  All  EL^**=NTS  within  an  ENTITY  should  be  USED,  UPDATED 

or  f'E'’TV’"D. 

i)  All  F’=‘LATIPN3  should  be  MAINTAINED  by  at  least  one 

D OOP'S  CS  , 

V)  All  F^l»TIf'N3  should  have  a DERIVATION  statement. 


V) 


VI) 


r Arr  voluw~ 

EVENTS  should  have  a HAPPENS  statement. 
T'^ocFSSFS  should  have  a HAPPENS  statement. 

SET?  should  have  a CARDINALITY  statement. 

should  have  a VOLATILITY-SET  statement, 
should  have  a VCI  ATI  LITY-KEMBER  statement. 
ENTTIIFF  should  have  a CARDINALITY  statement. 
t.»;r>-pTFS  should  have  a HAPPENS  statement. 
lunuTt;  should  have  a HAPPENS  s+'atement. 

OUTPUTS  should  have  a HAPPENS  statement. 
'ETA-^I0”3  should  have  a CAPDINALITY  statement. 
'^SLAT'^CNS  should  have  a CCNNECTIVITY  statement. 


CONDI'*':nv  or  PROC»^RS. 

b)  Tarb  ccNniTTDN  should  be  associated  with  at  least  one 
’='VEN”"  or  rpocPS?. 

c)  Each  CCNUTTirv  should  have  a TRUE  WHILE  or  FALSE 
WH'''T,’='  s*a  *om®n  t . 


SYS"' 

•pv  C T7 

All 

fc) 

All 

c) 

A 1 1 

'll 

All 

F) 

A 1 1 

f) 

All 

q) 

All 

h) 

All 

i) 

A 1 1 

1) 

All 

►) 

A 11 

S YTT 

KK  DYN 

a) 

Each 

VTT)  EY'’TE'1  p TJ^p '=’'57X S 

ra)  All  KEYW.T’PE,  A"'TPrEOTFS,  SOURCES,  SECURITIES  and 
TRAC^-if^YS  Should  AP^LY  to  some  other  URL  names. 


VI*'I)  DPp.T’J'C'"  '•i  NA  se  K^N"' 

a)  All  PRODLE'*-''rT'INE'»S  should  have  a KATLUOX. 

b)  All  -:'-nnrxjjrp5  should  he  RESPONSIBLE  for  the 

d«-scr  ip*  i on  of  at  least  one  URL  objects. 


"^abl  p 5.5a  (con*inued) 


T>  % C 
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fl61  8?/MnLT:cS/L?L  riS^E'S  rANUAL 


1 81 

Analyzer  CoTimanis  Comploteness  Checks 


in  FO"*'.  ATT  on  PTPCF"’ 
CONFIF-F  COrPAPTSON  FA'^PIX 
COFTENT*^  EFPOP'" 

DATA  FPOCEPS 

p’O^MATTFr  PRnpLFM  8‘^A'P''MFNT 


FP^’CMENCY  pfpop” 

NANP  PFF 
^TC'!'  HFF 

PROCFFS  TNPTl"'/nn7p'jT 
PU*’CErD  CO'1”EN'^  PNTFTEF 


Vila 

IIIC,  IITd,  IITe,  Illq 

IITc,  Illd,  Ille,  Illg 

Ic,  Id;  IVa,  IVb,  IVc,  I Vd , I Vf 

la-Ie;  ITa-IId;  Illa-IIIq; 

IVa-T  Vf, 

IVi,  IV1;  Va-Vk;  Vla-VTc;  Vlllb 
Va,  Vb,  Vh,  Vi 
Villa,  Vlllb 

la,  Ib,  Ic,  Id,  le;  Ilb,  TIC, 
TTd 

IVb,  TVc 

TVe,  IVj,  Vd  , ve,  Vg 


"•able  5.5b 

qtjs  paport.s  tha+-  may  be  used  by  Visually  Check 
for  Completeness  of  the  Problem  Statement 


oiyp-'  T (ITEF  FCOniPEEFNIS  LANSUAUR  WAHOAL 


AD-A054  096 


UNCLASSIFIED 


MICHIGAN  UNIV  ANN  ARBOR  DEPT  OF  INDUSTRIAL  AND  OPERA--ETC  F/6  9/2 
USER  REQUIREMENTS  LANGUAGE  (URL)  USER’S  MANUAL.  PART  I.  (DESCRI— ETC (U) 
MAR  77  D TEICHROEW*  A HERSHEY.  S SPEWAK  F19628-76-C-0197 


ESD-TR-78-127-V0L-1 


NL 


END 

DATE 

niMED 

6 -IQ 

DOC 


!K1  Pf'/’HJLTTCS/OP!  USEF'S 
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PSA 

^ E'^E 
XATF'^y 


Peoort 
COM  PA’’!  SON 


nNSis"? 


CON'^ENTS  n^’PCFE 


PAT’S  PFOCESS  REPORT 


OTCTI^V.APy  pppo?” 


•^'^rj^j'T'TPTrp  T|lIp-^c-. 

MS'^TOV 

FO^’EATTED  PPOPt.E’1 
STAT^rOK" 


ComDlf»tcness  Checks 

All  INPUTS,  OUTPUTS,  ENTITIES  and  GROUPS 
are  broken  down  to  ELEMENTS  at  the  lowest 
level . 

All  necessary  ELEMENTS  ace  defined  in  the 
data  structure  for  a particular  INPUT, 
OUTPUT  or  ENTITY. 

Ml  3ROUPS  and  ELEMENTS  belong  te  higher 
level  data  structures. 

All  SETS  broken  into  INPUTS,  or  OUTPUTS 
or  ENTITIES* 

All  INPUTS,  OUTPUTS,  ENTITIES  and  GROUPS 
arc  broken  down  to  ELEMENTS  at  the  lowest 
le  vel  . 

All  SETS  broken  into  INPUTS,  or  OUTPUTS 
ENTITIES 

All  INPUTS  BECFTVEU  by  some  PROCESS* 

All  INPUTS  USED  by  some  PROCESS* 

All  OUTPUTS  GENERATED  by  some  PROCESS* 

All  OUTPUTS  UEPIVED  by  some  PROCESS* 


Ml  EWTITTFS 

and 

SETS 

DERIVED  by 

some 

PROCESS* 

Ml  ENTITIES 

and 

SETS 

DERIVED  and 

USED  by 

some  PP.OCFSS* 
»11  ENTITIFS 

and 

SETS 

are  UPDATED 

and 

USED  by  some 
All  GROUPS  an 

PROCESS* 

d ELEMENTS  are  DEPIV 

ED  or 

UPDATFO  or  USED  bv  some  PROCESS* 


All  f> 

®nCESSES 

USE  data  and 

DERIVE  or 

"PDA" 
All  P 

E data* 
POCESSES 

which 

DERIVE 

data 

a Iso 

USE 

d a ta  * 
Ml  P 

POCF^SES 

which 

UPDATE 

data 

a Iso 

USE 

la  ta  * 

All  PROCESSES  interact  with  data  in  some 
wa  v* 

All  names  should  have  a narrative 
DFSCPIOTIGN  and 
^ESnNSIBLF-PPOSLFM-DEFINFR 

De*-ermines  which  EN'^ITIES  have  and 
do  not  have  ID^'NT'IFIEFS 

""he  description  of  each  name  can  be 
checked  against  all  possible  statements 
for  t-hat  name. 


* ''omnut er-a lied  analysis 
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’tbpOUEN'CY  ’’SP0F7 

Kwic  iwr^'x 

;;A'ir  gfn 

VA'^F  LIFT 


PIT"'f)’5F 


A ’'7T!  rrM"?*  prpo-T 


PPOC'£55  I'J'iTJ?/ 

pn-'PUT 


All  INPUTS,  COPTPrjTS,  PROCESSES  and 
EVENTS  should  have  a HAPPENS  statement 


All  names  of  a particular  type  (e.q., 
PFncESS)  have  been  defined  for  a 
particular  rroblem  statenent 

Hanes  which  have  synonyms  in  the  real 
world  should  have  them  in  the  problem 
s^  atemen  + 

[Given  in  Table  2. lb] 

All  names  should  be  involved  in  structure 
and/or  information  flow  of  the  problem 
St  at  em  en t » 

'll  ATTFISn'^ES  have  VALUES 
All  names  have  appropriate 
ATtpI  HnTES/ATT'’TBOTE  VALUES  assigned  to 
th  en 

Ml  PFOCFSS  interact  with  data 
ir  some  manner 

All  npocESFES  US’:"  or  RECEIVE  information* 
All  PROCESSES  gENERAT'=’,  DERIVE  or  UPDATE 
information  * 

All  PROCESSES  have  DSSCPIPTION  and 
PFPCEDUFE  statements 

Table  5.2 
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n^r"* 


r USEP  PFOUT^FEENTS  LANGUAGE  KANUAL 


r 


1 


I: 

r 

f 

)■ 
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rc  s nopQj^t 


Consistency  Checks 


^ONPiSTr  corPAPiso" 

CONSTSI^S  A T”’"' y 

COVT?!NT? 

PAT7.  FPOC??*^  P'POP'^ 


■»<  ,j  Y cpnopT 


IP^rTI='TPR 

''.ATIOr 


FO^r.  ATTr  n^rnf  v-ji 


P»>PQ  tjr»j0y  9>?pOj5T 


FWTC  INPr '< 


'Ih r-3y 


iiST 


'Similarities  in  data  structures  of  INPUTS 
nurpM"’'!  and  Fntities  can  he  rationalized 
for  a oarticular  problem  statement. 

betermines  whether  or  not  the  use  of  the 
CONSISTS  statement  in  describing 
structure  is  consistent. 

Determines  whther  or  not  the  use  of  the 
CONSISTS  statement  in  describing 
structures  is  consistent. 

Determines  whether  or  not  the  use  of 
RECZIVFE  and  OENFPATES  statements  in 
describing  the  system  flow  aspect  of  the 
system  is  consistent. 

Determines  whether  or  not  the  use  of 

gPDATFS  and  D5PIVES  statement  in 
describing  the  data  derivation  aspect  of 
the  system  is  consistent. 


Synonyms  and  descriptions  should  apply  to 
each  n\me  accurately 

Determines  whether  or  not  the 

ure  of  ICSNTTFIEFS  is  consistent  through 

the  problem  statement. 

Determine  whether  the  complete 
DSL  description  is  accurate  for  a 
particular  name  (e.g.,  check  that  the 
DFSC'^IDTION  matches  what  is  given  by 
other  PSL  statements) 

Determines  whether  or  not  the  manner  in 
which  frequencies  (HAPPENS  statement)  are 
assigned  is  consistent. 


Determiner,  whether  or  not  conventions 
ure-^  in  assigning  names  is  consistent 


Determines  whether  or  not  naming  is 
consistent 

De-termines  whether  or  not  name  types  have 
been  assigned  correctly. 


Determines  whether  or  not 
consi stent 

Determines  whether  or  not 
been  assigned  correctly 
Determines  whether  or  not 
been  assigned  correctly 


naming  is 
name  types  have 
SYNONrns  have 


i 


PI-,- 
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p I 'j  r F 


^'T>-"P  jprf^p  pPTion' 

PROC^’SS 

onTPU’’' 


Pet.prminps  whether  or  not  the  naie  the 
PTCT^JPS  is  qeneratei  for  relates  to  the 
structvire  and  inforaation  flow  aspects  of 
the  problem  statement  correctly 

Determine  whether  cr  not  the  conventions 
of  assigning  ATTRIBtJTKS  is  consitient 

Determine  whether  or  not  the 

manner  in  which  PROCESSES  are  described 

is  consistent 


Table  5.  2 (con't) 


PA'"'  r DSEF  "EyDIPFIENTS  LANGDAOE  MANUAL 


HSCEDINO  PACK  BUNEUNOT  FIIMBD 


PD/rnL-^TCS/tlRL  fJS’3R'S  MANUAL 


In'lex 


roTiDUtor  u,  15,  2'',  35,  ^ ic*?,  1*^5,  168,  169 

'4,  S,  11,  2?,  3«i,  16,  36  , 37,  38,  5«4,  55,  60,  7?,  108, 
l1->,  -16,  117,  125,  135,  161,  170,  171,  172,  178 
function  18,  ^o,  pa,  34^,  ^47,  luP,  149 
Inmuaqe  u,  r,  36,  37,  61  , ^2^  127^  3^7^  3^3^  3,50^  309 
svs--^ms  1,  6,  -lu,  28,  >=2,  60,  70,  1C6,  114 

APPLIES  26,  pf,  2-',  28,  72,  117,  1C8,  111,  1 14,  1 15,  160,  162, 
173 


nss 

rCT  ? e; 

• *-  ■ F 

26, 

32. 

107, 

109, 

112, 

120, 

141, 

145, 

-SI, 

-52 

f 

154, 

I85 

162 

ASSOCIA-'EO 

25, 

26, 

27,  3 

• 1 

$ 

2, 

73, 

74, 

A-^S 

'ic-’At^d 

1-  D A 

A pc. 

26, 

27, 

31 

TO 

9 ^ 

, 73 

S ?5’F  IBn”  7 

13, 

15 , 71 , 22 

, 25 

9 

26, 

23, 

i r 0 

f 

“'ll. 

1 12, 

1 13, 

118 

9 

120, 

124 

14=, 

l^lr 

152, 

154, 

155 

9 

156, 

157 

18''  , 

181, 

155, 

- P8 

ATT 

c I p rt'F  F- 

VAT,  'I 

5 15, 

15, 

7 1 

c.  1 , 

22 

, 32 

. 38 

120  , 

180, 

157 

n7Cf'"'’='S  1'-'*,  I''?,  -'^C,  154 
P'=’C6'- J'TVG  86,  07,  in-^,  363 

nP-wi:3V  25,  26,  72,  73,  74,  75,  7f  , 339,  343,  343,  375,  379 
Comman'1  112,  113,  11"' 

CA^DITJAIITY  2',  26,  27,  31  , 77,  81  , 95,  96,  134,  138,  14  1,  167, 
17?,  176,  1 O'* 

CA'JSfr  25  , 26  , 27,  3 1 , 88,  10'',  101,  154 

CAHSEE  26  , 27,  31  , 86,  87,  VIC,  127,  153,  154 

''T.  ArSTF--CA-rov  13,  1'’,  2-,  22,  2^,  27,  31  , 32,  38,  63,  80,  88, 

118,  127,  13P,  1 33,  134  , 1 18,  145,  160 

condition  13,  -5,  19,  31,  33,  38,  96,  87,  98,  lOO,  101,  102, 

118  , 127,  - 48,  IS'',  1S2  , 153,  154,  155,  176,  180 
CONNECTIVI'’y  28,  26,  27,  31,  75,  76,  91,  92,  95,  140,  14  1,  175, 

1«r 

CONSIS-F  28,  26,  77^  31^  77,  7?,  74,  75,  77,  78,  79,  91,  92, 

98,  126  , 128,  1 81,  1 32,  1 36,  143,  152,  166,  167,  17  4,  179, 
181,  182,  184 

C'TJSrr'FD  25,  26  , 87,  37,  103  , 104,  106,  157 

CDNSDNFS  25,  16^  37,  52,  1C3,  1C4,  105,  106,  156 

CON-* INTO  85,  26  , 27,  31  , 63  , 72,  73,  74  , 76  , 78,  79,  86,  90, 

°1,  8n,  12<;,  129,  131,  140,  142,  166,  167 


CON'''SP"!'S  70 

-»o 

r 

, 131, 

182  , 

1 84 

r^p-Nr  •>9^ 

1 18, 

I^S 

161, 

162,  164, 

173 

DFLFTE-PSL 

52 

DT^TVA-’-’nN 

IS 

2F,  ir. 

r 3-, 

??,  60, 

88,  137,  140 

, 141 

, 180 

DEo-’VF  4':, 

80, 

“1,83 

, 85, 

126,  132 

, 136,  143, 

144, 

147, 

164, 

1^8,  IF?, 

183 

OFFIVET 

26, 

25,  5 

1,  «0 

, 81,  84, 

88,  88,  90, 

130, 

131, 

133, 

i?6,  187,  144,  - 45,  146,  149,  164,  165,  166,  167,  168,  179, 
180,  183 

nPO-vES  ?8,  26,  57,  31^  91^  03,  94,  95,  99,  97,  99,  132, 

121  , 147,  1 48,  - 48,  167,  194 

nPcrpip-xON  1,  25,  ’0,  12,  38,  fl,  60,  89,  107,  108,  112  , 119, 
P»7'^  IT  MSFF  F5:0'JI*>EP.2NTS  lANOUAOE  PEFEF3NCB  HAITOAL 


f>(:i  PO/rinL^ics/nFi  nsER’*?  manual 


188 


12“ 

, 154, 

1 50, 

121, 

134, 

139, 

141, 

145, 

151 

, 162, 

1 54, 

155 

166 

169, 

^*59, 

162, 

182, 

183, 

184 

D6'S:0KA” 

F 56, 

-5  5,  5 8 

, 118 

, 163 

DTCT  TON  A 

FY  1 1 5 

, 192, 

1 94 

5'LE'i  Fl’i" 

“•B,  1-^ 

r 17, 

1«,  ^9,  2 

2,  31, 

39, 

39, 

69, 

70,  72 

» 73, 

74, 

'■'S 

78,  7q,  flc. 

PI, 

83, 

94,  85 

, 86, 

97, 

OR, 

89,  90,  91, 

95, 

112 

r 1*8, 

126, 

120, 

13G, 

131, 

132, 

133, 

1 J7 

. 140, 

1 42, 

143, 

144 

r 145, 

147, 

1 48, 

164., 

166, 

167, 

172, 

173 

, 176, 

179, 

180, 

182 

5'MTTi’Y  13,  15, 

16,  1 

7 10 

, 31 

, 38, 

70,  71,  72,  53,  74, 

75,  76, 

70,  qr,  03, 

O') 

9 

94, 

85,  86 

, 97, 

88, 

89, 

90,  91,  95, 

96 

IIP 

, 131, 

1 ’2, 

135, 

134, 

135, 

1 36, 

137, 

138 

, 139, 

140, 

141, 

142 

, 143, 

147, 

1 4°, 

161, 

164, 

165, 

166, 

167 

, 172, 

174, 

175 

176 

» 1'’”, 

1 85, 

1 82, 

184 

1?  ^ 1?  Ht  'Tl  5 

r IS 

15  , 53 

, "2, 

39, 

39,  91,  92 

, 95 

, 96 

, 97, 

98,  100, 

1^1 

ir 

0 

IIP, 

127, 

149  , 

150, 

163, 

154, 

155 

, 176, 

1 80, 

182 

’='AL<^E  OP,  °7,  -JR,  rr.,  ki,  ■'J2,  17^,  150,  151,  152,  153,  154, 
1«^ 


pt?rofiFjjcY  1^,  181,  1P2,  184 

r,EN'FA'"Fr  11,  I?,  25,  78,  27,  31,  3<>  , 56,  57,  58,  60,  65, 

67,  R7,  qo,  12a,  125,  1 28,  129,  131  , 164,  166,  179,  182 

r.PVE>;A-^S  1-1,  11  , 23  , 25,  26  , 27,  31  , 58,  59,  56,  57,  58  , 60, 

61,  06,  o-r^  167,  184 

r.FOM’?  15,  15,  1-^,  18,  22,  31,  5P,  3q,  69,  70,  72,  73,  74  , 75, 

78,  75,  8^*,  83  , 84  , -35  , 86,  88,  89,  90,  91,  95,  96, 

IIP,  156,  155,  130,  131  , 1 32,  1 53,  1U0,  142,  143,  1 44,  145, 

145,  lap,  184,  1 66  , 167  , 169,  172,  176,  179,  182 

27,  31,  01,  82,  05,  96,  127,  130,  149,  1 55,  165, 


ipr 

, 19 

*) 

9 

1 34 

T nT\; 

r 

FO  2 

c 

9 

26 

. 37 

» 3 

1,  ■’2 

9 

75 

, 74 

0 

78,  13 

TOFJ' 

T 

T 7?I 

2 

c 

9 

26 

9 <■  ' 

, 3 

S 70 

9 

74 

, 75 

9 

1 43 

I VCF 

r 

6^  ^ p 

V 51; 

9 

, 

2S 

51 

, ^7, 

98, 

ICO 

•' 

154 

-VC'' 

P 

"ir  *i-c  A 

c 

3S 

26, 

35, 

31 

9 

°7, 

10 

0,  150 

TNO't 

9, 

9 

IS 

16, 

17 

9 

23, 

^9 

, 31, 

3 3, 

38, 

39, 

66, 

57, 

C 0 

9 

Pa 

9 

9 

67, 

69, 

69 

9 

•’C, 

71 

, 72, 

73, 

74, 

79, 

80, 

81, 

f3. 

84, 

pc 

9 

8P, 

80, 

9C, 

01 

9 

°2, 

05 

, 96, 

97, 

98, 

100, 

, 101 

9 

112, 

11P, 

S’, 

124, 

SS 

126, 

127, 

128, 

131, 

135, 

1 36, 

142,  , 

146  , 

mo. 

1 40, 

140, 

S3, 

154, 

161, 

163, 

164, 

165, 

166, 

167,  1 

172, 

17P, 

S9, 

1 30, 

181  , 

1 32, 

183, 

184, 

185 

Tvnt''"-PSL  65 


-N5'FFFAr» 

1,  ’S  14,  15,  20,  31,  38 

, 39 

r 56, 

57, 

58, 

60, 

64, 

P7,  PP 

, 60 

, 00,  118,  123, 

124, 

125, 

128, 

129, 

1 35 

, 16  3, 

16a , 

1 6<^, 

176,  SQ 

T«'"c‘ r 0 rip  "■c'T  “JC 
* - — - , 

26, 

27,  5i,  PB, 

ICO, 

101 

, 149 

, 150 

- VT*" r P ft O'', 

27, 

.31,  07,  1''5,  127 

, 150 

, 153,  155 

TN''’5'F  VAT 

13,  1- 

, ’9 

, 19,  51,  18,  oc 

» 91, 

95, 

96, 

118, 

151, 

152, 

176 

ff^YWOFO  13,  I'', 

21, 

2 2,  25,  26  , 28  , 

S, 

38, 

S6, 

107, 

10  8, 

111, 

% 

113, 

’ 18, 

119,  *'20,  124, 

128, 

131, 

134, 

139, 

1 41 

, 145, 

19“, 

’92, 

1 94, 

156,  15.6,  157, 

158, 

159, 

163, 

161, 

162 

, 173, 

1-4,  18'' 

K'^rn  19  3,  19  4 

l^-rq-  <»74,  193^  194 

MAi-IRrv  13,  16,  21  , 25,  26,  28,  52  , 38,  114,  1 18,  116,  118,  159, 
161,  162,  17U,  17  = , 180 

Pip-  -r-  „^rp  F8nniE.P'iTi'N-:p  lanooaoe  p^pepekci:  manoal 


‘5  0/M  IJT  TICS/ nrL  f;SFW»«  fan'Jal 


189 


FAIF'^ATFf'D  28,  2 

6,  ?7,  31 

, 80 

, P4,  88,  1 40, 

141, 

161  , 

173, 

1 80 

F AINTAIF  S 

25, 

, 2-’,  71, 

35, 

80,  P.3,  148, 

149 

75, 

2S  27, 

57, 

98, 

1C1,  128,  150, 

151, 

155 

"’FASUPFO 

25,  28, 

27, 

32, 

1^3, 

104,  105,  157 

MEA'^nPF? 

2S  2^, 

27, 

32, 

103, 

104,  105,  158 

•'*••10  17, 

18,  21, 

22, 

32, 

706,  108,  109, 

111, 

113, 

118, 

121, 

174 

MAMrl-CFV  117,  111,  117 


73,  15 

, 16,  17,  23, 

29,  31 

, 33, 

38, 

39, 

56  , 57 

# 

6% 

54,  6-’, 

68,  89,  7C,  71,  72, 

73, 

74, 

79,  80,  81, 

83, 

P4,  8C, 

87,  P8, 

8Q,  90,  91,  0 

2,  98, 

96, 

112, 

118, 

123, 

128 

129,  130 

, 1 31, 

1 38,  136  , 1 37  , 

142, 

146, 

147, 

148, 

161, 

163, 

1f4,  16= 

, 168, 

167,  1-’8,  17Q, 

180, 

1P1, 

182, 

183, 

1 84, 

185 

Parampter  f*  ’ 
nfppoFMFO  28, 

?8,  27 

, 37,  10  3,  104 

, 108, 

106, 

151 

DrppoP”S  28, 

2S  27, 

103,  104,  1.?5 

, 1^6, 

186 

pir-'Tjp^  6 7,  6 8,  8Q, 

1P1,  183,  165 

PPORLEM-OPflN 

F7  13, 

i=,  21  32,  3P 

, 114, 

115, 

116 

, 118 

, 169, 

1P1,  174,  17R,  IP'' 

P70C-CMPF  rs,  3),  31,  51,  R'',  68,  89,  102,  149,  183 

ir,  11,  13,  18,  IP,  19,  20,  21  , 22,  23,  31  , 3 3,  37, 
3P,  37,  <5c,  57,  88,  6r,,  C4,  f8,  f7,  88,  69,  77,  79,  80,  81, 
P5,  0-4,  Of,  07,  op,  00,  00,  01,  Q2,  95,  96,  97,  98,  100, 


» 

101  , 

1C?, 

I'l'', 

1 04, 

105, 

1''6, 

112, 

118, 

119, 

120, 

121, 

124, 

128, 

'•28, 

127, 

12P, 

no 

, 

13^ 

132, 

133, 

134, 

136, 

1 37, 

130, 

1 

14C  , 

143, 

1 4 4, 

■'45, 

148  ^ 

147, 

14P, 

149, 

150, 

151, 

153, 

154, 

[i 

-ir  e 

^ = 6, 

167, 

1=9, 

161, 

164, 

165, 

167, 

172, 

176, 

179, 

180, 

IP  1 , 

182, 

^ 37, 

1 64, 

18  = 

■ 

D-jnr  p 

13, 

i e;  10 

' f 

, 20 

, 22, 

32, 

3F,  64 

, 67, 

90, 

88, 

103, 

1 04, 

i;r. 

1P6, 

1 1°, 

127, 

130, 

134, 

1 38, 

145, 

151, 

155, 

1 56, 

157 

PSA  ‘•o"',  184 
7SL  1^4 


^'^CF  I V?^ 

I*", 

^1, 

--  9 

2S 

28,  27 

, 71 

, 39, 

40, 

51, 

56, 

57, 

58, 

60, 

6*^, 

88, 

84, 

124 

, 125, 

12P  , 

129, 

131, 

, 164 

, 179, 

182 

Ty  T?C 

r 

23, 

24,  25 

, 26 

, 27, 

31, 

38, 

56, 

57, 

58, 

60, 

88, 

1?3 

, 146,  187, 

194 

rm  h 

u r 

TFO  ' 

'S 

26, 

27, 

72, 

73,  74, 

- $ 

132, 

167 

TIOV 

13, 

IS 

17, 

38, 

70,  72 

, 73 

, 74, 

75, 

76, 

77, 

80, 

8 3, 

84, 

"8, 

87, 

9 

92, 

95, 

119,  131, 

139, 

140, 

141, 

143 

, 148, 

167, 

174,  i7«^,  17f,  177,  IPO 

prqoocrr  13,  18,  20,  32,  38,  10’,  104,  108,  106,  118,  157,  158 
PFSOOPCr-tFAC,’  2",  26,  27  , 32  , 43,  47,  103,  1C4,  105,  106,  151 
»E.80nocr-78Ar,F-PAFA'' FTFF  13,  20,  ’P,  103,  104,  105,  106,  118, 
187 

F*‘snnrC''-'!FAr;*'-P  APiJ18T?‘»-VAL’IE  28,  26,  103,  158 


9P3PCr.STPT.='  25, 

2S 

27, 

32,  56,  97,  60, 

114, 

115, 

123, 

159, 

179 

180 

r ^ -7->n  V ~r  PLF-  I p F"  T 

r 25 

, 26,  27,  31,  57 

, 135 

P’"iPCN.8T  PL'’-  PPOPLFr- 

DEFINPP  25,  26  , 28, 

114, 

115, 

121, 

124, 

128 

131,  134, 

1 39, 

141, 

‘•45,  151  , 152, 

154, 

155, 

156, 

157, 

158 

180,  ‘•82, 

1 92 

crrnrT"y  13,  18 

, 21, 

22, 

25,  26,  28,  32, 

38, 

107, 

108, 

109, 

111 

113,  119, 

122, 

124, 

12P,  131,  134, 

139, 

141, 

145, 

151, 

152 

154,  1=5, 

158, 

157, 

153,  159,  160, 

161, 

162, 

173, 

174, 

180 

8FCM PI'Y- ACC F^S- SIGH"  25,  27,  80,  88,  124,  127,  130,  134,  145, 

no,  I'^e 

OA^"  T---  'jcjpp  ceo'’IPE.MFVTS  iangoage  pefsfbhce  hanom 


MSZF'S  »!ANtlAL 


190 


''PE-'IFMP  25,  25,  28, 

32,  167,  108, 

10°, 

111, 

121,  122, 

124, 

128, 

'•■'I  , 134,  1 30, 
1''9,  1^2 

141,  145,  151, 

152, 

154, 

155,  156, 

157, 

158, 

9,  11,  13,  15,  17,  20,  31,  37, 

3», 

=6,  57,  58,  60, 

64,  65, 

fi  i~>  "’T  7a 

75,  78,  70,  Pr,  31 

, 83, 

84,  85,  87,  88, 

89, 

op,  01,  oo^  0>;, 

05,  118,  133, 

125, 

126, 

129,  131, 

1 34, 

135 

135,  ‘'T',  1 3H, 

13°,  142  , 1 47, 

148, 

161 , 

164,  166, 

167, 

172, 

■•o#:,  170,  in'*. 

1 32 

STTPC5  10,  1C^  21,  ? 

2 , 2 = , 25,  7P, 

32, 

?8,  107,  108,  109,  111, 

113,  "IP,  170, 

124,  173,  131, 

134, 

139, 

141,  145, 

151  , 

152 

1=4,  is-^,  155, 

157,  1‘^R,  150, 

150, 

161  , 

162,  173, 

174, 

180 

c-npcTtfCP  01,  C3,  fq 

, 73,  17a,  170 

qfipPAP^o  25,  25,  27, 

31,  53,  G4,  65,  57 

69,  104, 

136,  124, 

125,  125,  170, 

ia7,  lao,  1=6, 

179 

q.j^cr-r  05  , 77  , 3 1 , 63  , 54  , 65  , 

68, 

1 35 

'^nns’^T?  25,  25, 

7 1,  6 3,  54,  67 

, 68, 

135, 

136,  179 

CrjTJ  q'^'T'"T\r;«"T5  TT^  p ~l 

2=,  25,  77,  31 

, 72, 

13=, 

136,  167, 

1 79 

O'TiS  IN ^-C Pin V 

1 3,  25,  26,  2 

7,  31 

r 3«, 

72,  73,  74,  118 

9 

142,  lao,  151, 

173,  174 

‘^fJ’irAFY  115 

SvnONY''  12,  13,  15, 

21,  25.  26,  2« 

, 32, 

38, 

1''6,  107, 

108,  112, 

113,  11=,  IIP, 

IIP,  124,  128, 

131, 

nu. 

139,  141, 

1 42, 

145 

i^l,  157,  i<^a, 

I^P,  134 

155,  10^,  157, 

150, 

150, 

162,  163, 

173, 

174 

qy  q'~  ry_p  on  VI  p ■"T'P 

15,  “'8,  19,  ? 

1,  38 

, 72, 

9'',  91,  92,  96, 

lop , IIP,  1 25, 

12P,  131,  141, 

152, 

161, 

162,  167, 

173, 

175 

-Tipovi  ^na^HD  2 •■ , 25,  7 

91,  97,  9P, 

109, 

1C1, 

149,  150 

■"lOKlNA’^FP  7c^  2=,  2 

o,  31,  07,  l^r 

, 127 

, 150 

, 153,  155 

“^^PT  INB '"ION  25,  25, 

27,  31,  07,  98 

, 10'' 

, 154 

INA"'TON-C  B'TO  ES  2 

S 25,  27,  31, 

97, 

100, 

150 

'V'TVP'*_pPC  ^77,  1 7^, 

140,  ICC 

•"PAri-Kpy  17,  15,  21 

, 23,  26,  28, 

32,  38,  1C 

7,  108,  109,  111 

r 

1‘'7,  113,  122, 

•’27,  124  , 128, 

131, 

139, 

139,  141, 

145, 

151 

152,  15a,  155, 

155,  1‘'7,  158, 

159, 

160, 

161,  162 

’"p-'OOEOpp  25,  25,  27 

, 31,  07,  98, 

no. 

101, 

102,  140, 

15  0 

■'PIIGEIP  25,  75  , 77, 

31,  07,  IOC, 

102, 

1 27, 

150,  153, 

155 

-T^rr^r  Of.  ^ 07,  C9,  i/'r',  in,  1C2,  129,  150,  152,  15.3,  154,  155, 

1 pr 


8pnA 

•"F  56,  6 0 

, =>0,  «1, 

°3,  H5,  12^- 

, “'32 

, 133 

, 136 

, 1'*3, 

144, 

147 

, n = 

, 102, 

1 83 

n-'DB 

"■pO 

n,  2 

5,  2S 

n. 

31, 

56,  57 

, 58, 

82, 

34,  88,  89, 

90. 

131, 

137 

» 137 

, 1 44, 

1 45 

, 148 

, 164, 

167, 

IPR, 

180  , 

182 

»I7  3A 

TPS 

n,  11,  2", 

f 

*•  ’ 9 

27, 

31  , =6 

, 58, 

80, 

81,  83,  84, 

85, 

86, 

«7. 

8°, 

I'lP,  iu 

0 

9 

n7. 

1P4 

no  \ 

'4, 

. 11, 

■'2 , oa 

, 35,  36 

, 37, 

40,  51,  =2 

, 57, 

54,  55,  67 

9 

PP, 

n7. 

113,  ' 

16, 

120, 

124, 

163, 

168, 

169,  170,  171  , 

n? 

. 17« 

, 181 

7 PL 

, 6, 

8,  °,  n. 

n,  ' 

2,  13, 

1*4, 

16,  18,  20 

, 21, 

22,  23, 

24, 

?5, 

2°, 

31 

, ^2, 

J**,  2 

5,  36 

, 37, 

38. 

39,  40 

» “Ir 

51, 

M, 

5a,  rc. 

cc 

, 57, 

38, 

2,  63 

, 66. 

67. 

69,  70 

. 73, 

74 

n. 

7S 

7P,  82, 

PR 

, “9, 

00,  0 

2,  05 

, 10? 

, 104 

, 106, 

107, 

n8 

,111 

, 112, 

•'  13 

, 314 

, n5. 

116, 

in. 

118, 

120, 

1 21  , 

122 

13° 

i q 0 

, 16^, 

161 

, n2 

, 16-3, 

164, 

167, 

169, 

169, 

170, 

171, 

1-’'? 

173 

, na. 

17  = 

, 180 

05IVG  70 

, ai. 

RT  , PC 

, 88,  89 

, 112, 

121, 

130, 

133, 

137. 

141, 

144 

14P 

, 16? 

, 18'' 

pn?""  TI  T'=:C)rjIF?:?!ENTS  tANGHAGE  PEfEPENCE  HAITI 


!I^  1 PO/M.rjT.TICS/TlPL  nSKwiS  !^A*»nAL 


191 


M-TLI’;:'’  If-,  (=3,  fu,  f.5,  f>7,  qu,  89,  147 

'I'^riT7'S  2'^,  2f,  27,  31  , 63,  ^U,  6'^,  67,  68,  8tt,  147 
VAT.n^c  26,  2-',  72,  74,  01  , 95,  104,  106,  111,  145,  162, 

173,  17*^,  183 

VOL«"‘IL'^"'Y  2*^,  17,  ■»1,  9c,  134,  167 

f UI.ITY-'I' '*^7  0 25,  8'',  31,  139,  190 

VOLATILT^v-s  K-"  28,  S'",  31,  138,  ipc 

WMTL?  2^,  3C,  31,  01,  99,  191,  102,  152,  153,  174,  180 


I 


1 

1 


j 


pfc-  TT  .fccp  r®0'»T*F1EKT5  LAMGOAGE  REFEREKCS  HANUAL 


